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Abstract 


For engineering software with formal correctness proofs it is crucial that proofs can be effi¬ 
ciently reused in case the software or its specification is changed. Unfortunately, in reality 
even slight changes in the code or its specification often result in disproportionate waste 
of verification effort: For instance, whenever a method’s specification is modified and as a 
consequence the proof of its correctness breaks, all other proofs based on this specification 
break too. Abstract method calls is a recently proposed verification rule for method calls 
that allows for efficient systematic reuse of proofs. In this thesis, we implement, extend and 
evaluate this approach within the KeY verification system. 
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Chapter 1 


Introduction 


1.1 Motivation 

One of the distinctive features of modern software is that it has changed from static to 
constantly evolving products. That means frequent changes to accommodate new client 
needs, to optimize existing functionalities and, of course, to fix discovered bugs. It has 
also become standard in software industry to assure software’s correct behavior with help of 
testing, which, as it is well known, can only show the presence of bugs and not their absence 
(DDH72j. While just testing the software may be sufficient for many every-day application 
scenarios, there are other areas like avionics, automotive or medical engineering, where the 
correctness of software is a much more critical requirement. 

Software verification with formal methods has emerged as a mean to mathematically prove 
the absence of bugs in a program, or more precisely, that a program functions as intended. 
However, in the current state of art the costs of formal verification of a non-trivial piece of 
software are still very high. Although several successful steps have been made on the path 
of automation of software verification, it is still far from being a push-button technology and 
often requires interaction by an experienced verification engineer. 

The fact that modern software has become constantly evolving further worsens this sit¬ 
uation. Even slight changes in code may result in disproportionate waste of specification 
and verification effort. For instance, whenever a method implementation is modified and as 
a consequence the proof of its correctness breaks, then all other proofs based on this one 
break too. Whereas a naive and straightforward approach in this case would be to start the 
verification of the affected methods from scratch, we aim at saving the effort by reusing parts 
of the old proofs that remain unaffected by the changes. 

In this thesis we extend the recently proposed approach for effective systematic reuse of 
proofs jHSBldl in the context of the KeY verification system. 

1.2 Context 

The KeY system is a formal verification environment that uses dynamic logic to deductively 
prove the correctness of programs written in the Java programming language. It’s specifi¬ 
cation methodology follows the design by contract approach suggested by Meyer |Mey92| in 
which the notion of program correctness is expressed through contracts - mutual obligations 
binding program components. Relevant components of an object-oriented program being 
class methods, a behavior of a method m is captured in form of a contract with a precon¬ 
dition P and a postcondition E. The intuitive meaning is similar to that of a Hoare triple 
{P}m{E}: if the method m is called in a state satisfying the precondition P, then, assuming 
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termination and determinism of the programing language, the postcondition E should hold 
in the resulting state after the execution of m. 

KeY translates the source code and the provided method contracts into formulas of dy¬ 
namic logic fHTKOO) . also called proof obligations. More precisely, the KeY system uses Java 
Dynamic Logic (JavaDL) which is an extension of the first-order predicate logic with modal 
operators for handling executable code fragments written in the Java Card language. 

The main underlying verification technique of the KeY system is symbolic execution, a 
process during which code fragments appearing in formulas are gradually transformed into 
state updates - syntactic representation of changes caused to the state of program variables 
by execution of the code. Symbolic, instead of concrete values are used for the variables, 
hence the name of the process. After symbolic execution is completed, the resulting first- 
order predicate logic formulas are proved, either within KeY itself, or are handed over to 
external satisfiability modulo theories (SMT) solvers, which may offer better performance. 

A successful attempt of proving a formula indicates correctness of the method under 
verification with respect to its specification formalized in a method contract. KeY system 
supports specifications written in Java Modeling Language (JML) )LBR06| or its own input 
format. Proof search may be done interactively inside the graphical user interface by applying 
calculus rules to a formula (a list of applicable rules is suggested by KeY) or it may be 
performed automatically by using predefined proof search strategies. 

The question of how to handle method calls during symbolic execution is in the focus of 
this thesis. Currently KeY offers two possibilities. The first one is to substitute a method 
call with its concrete implementation, which is a simple but highly ineffective approach in 
a scenario where the method implementation is expected to be frequently modified. The 
second possibility is to substitute the method call with a declarative specification of its 
effects (a postcondition). For this to work, two things are necessary: the called method has 
to be successfully verified against its contract and its precondition has to hold in the state 
when it is called. Using the method contract provides a great level of abstraction from the 
implementation, but considering that any significant change to the method is most likely to 
affect its behavior and would require an adaptation of its contract, the proof of the callee 
would have to be redone from scratch. 

An idea how to further increase the degree of independence of a proof from specifications 
of called methods was proposed by Hahnle, Schafer and Bubel IIISBl.'ll under the name of 
abstract method calls. According to this concept, a method call is substituted by an abstract 
version of its contract that contains non-specific pre- and postconditions. Symbolic execution 
continues until only first-order logic proof goals remain, after which the actual definitions of 
pre- and postconditions are used to finish the proof. This way its significant part, mainly the 
symbolic execution of a program being verified, remains independent of the specifics of called 
methods and may be reused if a proof has to be repeated to accommodate modifications 
in method contracts it builds on. When complex source code is verified, such as programs 
containing loops and requiring user interaction for successful verification, the possibility to 
reuse parts of the proof and save user interaction effort becomes extremely valuable and 
improves the modularity and the automation of verification. 

1.3 Contributions 

A major goal of this work is to increase the level of abstraction from method calls during 
symbolic execution of a program and to seamlessly integrate the concept of abstract method 
calls into the workflow of program verification. It is carried out in context of the KeY system 
and the JML. The main contributions of our work are the following: 

• We extend the set of specification forms that may be defined abstractly with abstract 
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locations sets and abstract class invariants. We provide supporting formal definitions 
and extend the JML to cover abstract specifications. 

• We adapt the JavaDL logic to correctly handle abstract method calls 

• We adapt verification workflow of the KeY system to facilitate automatic reuse of proofs 
by clearly separating and caching reusable proof parts. Necessary changes are made to 
the graphical user interface and to the proof search strategies. 

This thesis is structured as follows. Chapter [2] provides the background on the JML and 
the Java Card DL to the extent relevant for the introduction of the Abstract Method Call 
approach. In Chapter [3] we give the detailed description of this approach, introduce formal 
definitions of abstract invariants and extended abstract contracts and describe changes to 
the JML. Chapter [4] focuses on the implementation of Abstract Method Call in the KeY 
verification environment. In Chapter [5] we report on the results of empirical evaluation of our 
approach. In Chapter [6] we discuss the research progress in the related area and in Chapter 
[7] we conclude the thesis by summarizing the results and by setting up directions for future 
work. 
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Chapter 2 


Background 


2.1 Java Modeling Language 

The Java Modeling Language is a language designed for writing specifications about Java 
programs. It combines the ideas of the Eiffel language Mey88] and Larch language family 
[GH93 ], thus belonging to the class of specification languages following the design by contract 
concept. It has been developed since 1998 [LBR98] by a group of researches led by Leavens 
and has since then established itself as the de-facto standard in the area of design by contract 
style specifications for Java. 

In this section we provide a brief introduction of the JML features relevant for this thesis. 

2.1.1 JML in source code 

JML specifications for a program may be provided in a separate file, but a more com¬ 
mon style is to integrate them into the Java code as annotations. A JML annotation is 
a standard Java comment, which is ignored by a Java compiler, but detected by JML 
tools thanks to an additional marking with an at-symbol (@). Both single line comments 
( //@ invariant <boolean JML expression >) and C-style comments (/*@ invariant 
cboolean JML expression> @*/) are accepted. Such integration facilitates the reading of 
specifications and thanks to the rules regulating where the specification elements have to 
be inserted, clearly indicates the connections between them and the corresponding class ele¬ 
ments. 

2.1.2 JML expressions 

JML expressions are the basic building blocks of JML annotations used to write assertion 
predicates appearing directly after keywords like invariant, requires and ensures and 
describing state properties. The structure of a JML expression can be shortly described as 
follows: 


Java expression - side-effects + first-order logic + \old, \result, ... 

The syntax of JML expressions builds on that of the Java expressions to enhance its practi¬ 
cability and to make specification writing more convenient for programmers without special 
knowledge of formal methods. However, some restrictions and extensions are necessary to 
bring the Java language up to a required level of expressiveness. On the side of restrictions, 
JML prohibits use of any Java expressions with side-effects, like x = y + 10, i++ or a call to 
a state changing method, because a specification should have a purely logical meaning. On 
the other hand Java syntax is extended with some features of first-order logic: 
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• logical connectives ==> and <==> 

• quantified expressions (\f orall T x; bl; b2), with a meaning that for all instances x 
of type T for which the expression bl holds, expression b2 must hold too and (\exists 
T x; bl; b2), with a meaning that there exists an instance x of type T for which both 
expressions bland b2 hold. 

And, last but not least, there are special keywords: 

• \old(e) is used in postconditions to refer to the value of an expression e right before 
a method execution 

• \result is used in postconditions to refer to the return value of the method 

• \fresh(e) is a boolean expression that equals true, if an object to which e refers did 
not exist before a method execution 

2.1.3 Method contracts and class invariants 

The JML focuses on the formalization of the intended methods 1 behavior of the class that is 
being verified. For this reason method contracts are regarded as the main feature of the JML 
and moreover, they are of the highest interest for our work. 

public class Person { 

private /*@ spec public @t=/ String name; 
private /*@ spec.public @*/ int weight; 

//@ public invariant !name.equals (””) &&; weight >= 0; 

public normal behavior 
@ requires kgs >= 0; 

@ ensures weight = \old (weight) + kgs; 

@ assignable weight ; 

@ also 

@ public exceptional behavior 
@ requires kgs < 0; 

@ signals (IllegalArgumentException) weight = \old( weight ); 

@ 1 =/ 

public void addKgs(int kgs) throws Illegal Argument Except ion { 
if (kgs >= 0) { weight += kgs;} 
else { throw new IllegalArgumentException() ;} 

} 

/ /@ normaLbehavior 
//@ ensures \result = weight ; 
public /*@ pure @*/ int getWeightQ { 
return weight ; 

} 

public Person(String n) { ... } 


Listing 2.1: Implementation of the class Person annotated with the JML 

Let us consider an example taken from [LC06] and concentrate on the formal specification 
of the method addKgs (lines 7 to 15). As we see, a method can have several contracts, 
separated by the keyword also. A contract, as well as a class invariant, is preceded by a 
visibility modifier, in this case it is public. The JML inherits the visibility system of Java: 
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a specification may not address a field or a method of lower visibility level than itself and a 
method contract may not be of higher visibility level than the method it specifies. To make 
an exception to these rules the keyword spec_public is used (lines 2 and 3). It makes the 
fields name and weight public for specifications without affecting their Java visibility. 

The keywords normal .behavior and exceptional .behavior declare two different types 
of method contracts: the first one does not allow that an uncaught exception is thrown during 
the method execution, while the second one demands it. A precondition of the method can be 
declared with the keyword requires and a postcondition (if we specify the normal behavior 
of the method) can be declared with the keyword ensures. Their meaning is that if the 
precondition holds in the pre-state, then the method should terminate normally and the 
postcondition should hold in a post-state. Several requires clauses are joined by conjunction 
(same applies to postconditions). If a precondition misses, it means there are no obligations 
on the caller, which is equivalent to writing requires true (missing postcondition implies 
ensures true). The postcondition on line 9 tells, that after the normal execution of the 
method, the value of field weight (in the post-state) equals the value of weight + kgs in 
the pre-state. In a contract for exceptional behavior the postcondition is declared by the 
keyword signals followed by the type of an exception to be thrown and by the boolean 
JML exception specifying the post-state. Alternatively, the keyword signals.only may be 
used followed by the list of accepted exceptions only. 

The assignable clause specifies frame conditions, namely what locations may be assigned 
by the method. The keyword assignable is followed by a list of so called store-ref expres¬ 
sions or one of the keywords \everything, \nothing. Several assignable clauses are inter¬ 
preted as a union and an absent assignable clause is equivalent to assignable \everything. 
An assignable clause does not prohibit allocation of new objects or assignments to local vari¬ 
ables of the method. 

The class invariants express consistent properties of a class object, that are established by 
the constructor and that must be preserved through object’s lifetime. They must be preserved 
by method calls, that is if invariants hold before the method execution, they have to hold 
afterwards. To establish this requirement, invariants are implicitly included in pre- and 
postconditions of every public method and in postconditions of constructors. The invariant 
in line 9 states that the value of the field name never equals an empty string and that the value 
of the field weight is never negative. It would have been expected to include the condition 
name ! = null too, but actually it is a default requirement for any field in the current version 
of the JML (it may be changed by annotating a field with the keyword nullable). The 
modifier pure appearing in line 26 tells us, that the method getWeight has no side-effects 
and may therefore be called to in JML expressions. 

Some other clauses, not appearing in this example but available in the JML are diverge 
clause and accessible clause, diverge b states that the method is allowed to diverge, if the 
expression b holds in a pre-state and accessible jstore-ref list,/, defines locations that may 
be read by the method. 

2.1.4 Further features of the JML 

Loops might be annotated with loop invariants , which are afterwards used to show the cor¬ 
rectness of a postcondition. The keyword loop.invariant is used to specify what stays 
invariant (should be valid in a state right before the first iteration and after an arbitrary 
number of loop iterations), the keyword decreases indicates a variant integer expression 
which is strictly decreased by the loop body and which has to be >= 0 after every loop it¬ 
eration to prove termination of the loop and the keyword assignable states what locations 
may be modified by the loop body. The loop invariant annotations appear in the method 
body right before the loop itself. Other features of JML are data abstraction ( model fields 
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and represents clauses ), assertion statements, model programs, etc., but they are not in focus 
of this thesis and therefore, are not explained in this section. 


2.2 Java Card Dynamic Logic 

For the purposes of design by contract verification we are in need of a logic, that could 
express a statement of the following kind: ”if the precondition P holds, then the program 
p terminates and afterwards the postcondition E holds”. The suitable logic was proposed 
by IHTKOOI under the name dynamic logic (DL). It is an extension of typed first-order logic 
with two modality operators: [•] called box modality and (•) called diamond modality. A DL 
formula {p) E with a program p and a postcondition E is used to formalize total correctness, 
meaning that the formula is valid, if the program terminates and the postcondition holds 
afterwards. Alternatively, with the box modality one can express partial correctness: if the 
program terminates, then the postcondition must hold, but non-termination is also allowed. 
The dynamic logic used in the KeY system is tailored to the subset of Java programming 
language called Java Card [BecOOj and in this section we present its syntax and semantics in 
the extent relevant for this thesis. At the moment of writing we consider (BHS07) and j Wei 11 j 
to be the best sources for the full account of the Java Card DL, which have also served as 
the basis for this section 


2.2.1 Syntax 

Definition 2.1 (Signature). A Java Card DL signature T, is a tupel (T, C. F, P, V, PV, 
a, Prg), consisting of 

• a set T of type symbols (or simply typesj 

• a subtype relation C CTxT 

• a set F of rigid function symbols 

• a set P of rigid predicate symbols 

• a set V of rigid logical variables symbols 

• a set PV of non-rigid program variables symbols 

• a typing function a : F U V U PV —X T + . We write r v instead of a(v) = r, p(r\,..., r n ) 
instead of a(p) = (ri,...,r n ) and t /(ti, ...,t„) instead of a(f) = (ti, ..., r n , r) to denote 
the signatures of variable, predicate and function symbols. 

• a program Prg - any valid set of Java Card classes and interfaces. 


The set T gathers all the types that may be used inside Java Card DL formulas. This 
includes basic types like boolean and int, but also all built-in API reference types (like 
java.lang.Throwable, java.lang.Exception, java.util.AbstractCollection and etc.) 
and any user-defined reference types. To reflect the concept of class inheritance in Java Card 
programs, we introduce a subtype relation C CTxT, which orders the elements of the set 
T. For example, classes Vehicle and Car of program Prg both appear in the set T under the 
same names, and if the class Car inherits from the class Vehicle, this relationship will be 
captured by a tuple (Car, Vehicle) G C. Further basic types present in any Java Card DL 
signature are hierarchically depicted in Figure 2. l|p~ 


In the syntax of Java Card DL we strictly differentiate between rigid symbols, whose 
interpretation is the same in all program states and non-rigid (flexible) symbols, whose 
interpretation is dependent on the state. So for example, all typical elements of the predicates 
set (<, <=, etc.) and of the functions set (TRUE, 0, 1, +, *, etc.) are rigid. In contrast to 
predicate and function symbols, we distinguish two disjoint sets of variables V and PV , such 


1 Source: Dynamic Logic slides from Formate Grundlagen der Informatik 3, TU Darmstadt, WS 2013/2014 
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Figure 2.1: Type Hierarchy for Java Card DL 


that V n PV = 0. Elements of the set V are logical variables declared in first-order logic 
quantifiers and cannot be used in modalities. Elements of the set PV are program variables, 
whose semantics can be changed by the program and that can appear both in modalities and 
first-order logic parts of the Java Card DL formulas. Consider an example: 


Bint i; [x = 1;](x = i). 


In this formula int i G V, int x G PV and boolean = ( int,int ) G P. 

Note 2.1. We require that for any Java field f of Prg there is a constant symbol f G F of 
type Field. 


Note 2.2. We model dynamic memory with a global program variable heap G PV of the type 
Heap G T. We use the function symbol any select(Heap, Object, Field) to read from the heap 
at a specified position, the function symbol Heap storefHeap, Object, Field, Any) to write in 
the heap at a specified position, the function symbol Heap create (Heap, Object) to create an 
object on the heap and the function symbol Heap anon(Heap, LocSet, Heap) to anonymise the 
heap. 

Definition 2.2 (Term). A term of type r G T is either 


a variable v G V U PV of the type r 

a function f(ti,...,t n ) with the result type r and t\, ...,t n - terms of correct types with 
accordance to the signature of f. 

an updated term {u}t for an update u (Definition 2.3) and a term t of type t. 


Note 2.3. We use a separate type LocSet to refer to a set of pairs ( o , f), where o is a term 
of type Object and f is a constant symbol of type Field. We add function symbols U, fi and 
\ and predicate symbols G, C defined on the type LocSet. 


The update concept is one of the most principal in Java Card DL. It serves as a mean to 
keep track of state changes occurring during symbolic execution of the program appearing in a 
formula (Definition |2.4[ ). Its main difference from the more common approach of substitutions 
is that it allows to simplify and resolve conflicts of state changes at an early stage, postponing 
the application of substitutions to the variables till only after the symbolic execution of the 
whole program is complete. 


Definition 2.3 (Update). An update is either: 
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• a simple update pv := t for a program variable pv and a type consistent term t 

• a parallel update u\\\u 2 for updates u\ and U 2 

For example, a Java Card DL formula (x = l;x = 2)(x > 0) is transformed into {x := 
l}(x = 2)(x > 0), then into {x := l||x := 2}()(x > 0), where a parallel update is simplified 
into {x := 2}(}(x > 0) and then applied to a variable 2 > 0 

Definition 2.4 (Formula). A Java Card DL formula is either 

• TRUE, FALSE 

• a predicate p(t\,...,t n ) with ti,...,t n - terms of correct types with accordance to the 
signature of p 

• —if), (f> A if, f) V fi, f> —> if, (j) o if, Vr x f> and 3t x f> for any Java Card DL formulas 
f), if, any variable x G V and any type t G T. 

• \p](j) and {p)(j) for any program p and a Java Card DL formula <f 

• an updated formula {u}f> for any update u and a Java Card DL formula f> 

2.2.2 Semantics 

As usual in dynamic logic, we define the semantics in terms of a Kripke Structure: 

Definition 2.5 (Kripke Structure). A Java Card DL Kripke structure is a tuple K = 
(T>, 5,1, S, g) consisting of 

• a domain T> and a typing function 5 : T> —> T 

• an interpretation function T for predicate and function symbols 

• a set of states S consisting of functions s G S mapping any program variable pv G PV 
to a value d G V 

• a transition function g, such that for any program p and any two states s\, S 2 G S it is 
defined as g(s\,p ) = S 2 iff the program p started in the state si terminates and its final 
state is S 2 , otherwise it is undefined. 

The above definition of a transition function implies, that any program is deterministic, 
but does not necessarily terminate. We omit the exact definitions of the domain T> and the 
interpretation function I which can be found in their full extent in [Weillj . 

2.2.3 Calculus 

Similar to the first-order logic we show the validity of a Java Card DL formula in terms of 
the sequent calculus. The sequent T ==> A is said to be valid, if for any state s G S holds 
s |= r ==>• A. The validity proof of a sequent T A is constructed in form of a proof tree 
of calculus rules. We use the classical notation notation to define the calculus rules: 

, m Pi---Pn 
ruleName - 

c 

which means that the conclusion sequent c is logically valid if all premisses p\ ■ ■ ■ p n (also 
sequents) are logically valid. Alternatively we define rewrite rules in form left •w right which 
means that an occurrence of the schematic term left in any formula can be replaced with the 
term right , for example t = t TRUE. 

The calculus of Java Card DL consists of hundreds of rules that may be divided into 
two groups: first-order logic calculus rules and rules for symbolic execution of the programs 
appearing in modalities. The latter handles the control flow of the program, simplification of 
complex expressions and modeling of state changes. The symbolic execution calculus rules 
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are applied to the first active statement of the program. For example, assignments to local 
variables and object fields are converted into equivalent updates: 


T {x := t}(u]}(j),A 

assignLocal ----- assignField 

r =^- (x = t] a 


r =>■ {heap := store(heap, o, f, t)}(u)(j), A 
T =>- (o.f = t ; u)(j), A 


Complex expressions as i = x++; have to be transformed into several simple sub-expressions 
int temp; temp = x + 1; i = k using temporal variables. Update applications may be 
carried out on variables, functions, predicates and first-order logic formulas, for example: 


{x := t}y 


{x := t}x -w t 


{x := t}f(t i, /({x := t}ti ,..., {x := t}t n ) 

where x,y are program variables, x 7^ y, / is a rigid function symbol and t\,... ,t n are terms. 

The handling of method calls is of special interest for this thesis. As an alternative to 
substituting the method call inside the calling program with the body of called method its 
contract can be used. A simplified version of a useMethodContract rule is given in Definition 
It can be applied only in the context where partial correctness is to be proven and thus, 
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does not place any demands on the termination of the called method. Furthermore, we omit 
the requirements on the well-formedness of the heap and the reachability of input and output 
variables, as being not introduced in this thesis and not relevant to our topic. The definition 
of the useMethodContract rule in its full extent can be found in (Weilll p. 147] 


Definition 2.6 (Rule useMethodContract ) 


T ==> {u}{w}(pre), A 

T => {u}{'in}{heap ?,re := heap}{w}(post — > [r = res-,u]4>, A 
T =^> {u}[ r = o.m(ai,... a n ); u](j), A 

where: 


• o is the receiver of the method m and ai,...a n are its actual parameters 

• the Java Card DL formulas pre and post are the pre- and postcondition of method m ’s 
contract 

• the term mod of the type LocSet is the modifies clause of method m ’s contract 

• the program variable res represents the result value of the method m in the formulas pre 
and post 

• w = (self := o || p, := a\ || ... || p n := a n ), where self and p 1 ...p n are pro¬ 
gram variables representing the receiver object of the method and its parameters in the 
formulas pre and post and the term mod. 

• v = (heap := anon (heap, mod, h') || res := a), where h' and a are fresh constant 
symbols. 


The first premiss of this rule formalizes the requirement, that in the state at invocation 
time, the precondition of the contract should hold. In a different branch, which corresponds 
to the second premiss, the postcondition is used as an assumption to prove the validity of the 
rest of the formula at a state after the call. The update w replaces all the formal variables 
used in the contract with their actual values at the time of the call (the object and the passed 
arguments). The update v used in the second premiss is called an anonymising update. It 
formalizes an idea, that without performing the explicit symbolic execution of the body of 
method m, we cannot know the values stored on the heap, as well as the result value, in the 
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state after the call, so they are updated with unknown values with help of fresh symbols. 
In contrast to res variable, the anonymisation of heap is handled in a special way: only 
locations mentioned in mod clause have to be anonymised - other locations are specified as 
non-modifiable and therefore their values stay the same as in the state before the call. The 
semantics of a subsequent select operation on such an anonymised heap is reflected by the 
following simplified (the aspects of object creation are ignored) rewrite rule, which full version 
can be found in [Wei111 p. 94]): 

select(anon(h , s, h'), o,f) if (o,/) E s 

then (select(h r , o,/)) else (select(h, o,f)) 

where h is the ”original” heap and h! is the ’’anonymous” heap and which states, that for 
any location not in s select returns the value from the original heap. 

Note, that local variables of the caller also stay unchanged, because they are not visible 
to the method m. 

A similar idea is used for loops appearing inside the program. They pose exceptional 
difficulty to symbolic execution, mainly because expanding the loop body only makes sense if 
the bound on the number of loop iterations is literally known in advance, which is seldom the 
case. Instead, the body of the loop is substituted with the loop invariant. In Definition |2.7| we 
present a simplified version of a looplnvariant rule. It is applicable in the context of partial 
correctness and does not establish the termination of the loop. Furthermore, for the sake of 
simplicity it assumes that the loop body does not contain return, break or continue and 
does not throw exceptions. As for the useMethodContract rule, we omit the requirements 
on the well-formedness of the heap and the reachability of input and output variables. The 
full version can be found in [Wei111 , p. 108] 

Definition 2.7 (Rule looplnvariant). 

T =>• {«}(»), A 

T =>■ {u}{pre}{v}(inv A g = TRUE —> [p\(inv A frame), A 

T =>■ {u}{pre}{v}(inv A g = FALSE —> [uj\<f, A 

T =^> {u}[uhile(g)p; u\(f>, A 

where: 

• a Java Card DL formula inv is a loop invariant 

• a term mod of the type LocSet is a modifies clause of the loop 

• bi,...,b n E PV are the program variables that can potentially be modified by the loop 
body 

• v = (heap := anon (he ap, mod, h) || bi := b\ || ... || b n := b' n ), where h, b\,..., b' n are 
fresh constant symbols. 

• pre = (heap pre := heap || b l (" := bi || ... || bff' : = b n ), where heap pre , b^ 7t ,..., b„ re 
are fresh program variables. 

• a Java Card DL formula 

frame := V Object o; V Field /; ((o, /) &{pre'}mod 

V select( heap, o, f) = select( heap pfe , o, /)) 

• pre' = ((heap := heap pre || bi := bf" || ... || b n := bj] re ) 
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The first premiss of the rule requires, that the invariant holds in the state before the first 
iteration. The second premiss is close to an induction step: assuming that the invariant holds 
after an arbitrary number of iteration, it has to be proven, that it holds after another one 
(p - the body of the loop - has to be analyzed once). To reflect that the state has changed 
after an arbitrary number of iteration we again use an anonymising update v. In contrast to 
method contract rule, it also includes potentially modifiable (appearing on the left side of the 
assignment statements inside the loop body) local variables. A separate task is to prove that 
the frame condition (a statement, that only locations appearing in the modifiable clause may 
be changed by the loop body) holds. The update pre buffers the values of the state before 
the first iteration of the loop, and the update pre' uses them to inverse the anonymisation 
for mod term only. The last premiss formalizes the exit out of the loop. Assuming that the 
invariant holds after all iterations of the loop, the rest of the formula has to be validated. 
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Chapter 3 

Abstract Method Call 

3.1 Abstract contracts at a glance 

In the introduction to this thesis we have spoken of modular verification as the motivation 
for our work. More exactly we have identified as our goal the improvement of the reusability 
of proofs that rely on method contracts. A typical scenario in which the problem of such 
reuse arises, is illustrated by our running example, which we introduce now. 


1 class StudentRecord { 

2 // exam result 

3 int exam; 

4 

5 // achieved bonus 

6 int bonus; 

7 

s // minimum grade necessary to pass the exam 

9 int passingGrade; 

10 

n // completed labs 

12 boolean [] labs; 

13 

14 / /@ public invariant exam >= 0 &fc bonus >= 0 &fc passingGrade >= 0; 

is //@ public invariant labs.length = 10; 

16 

17 // 

is int computeGradeQ { ... } 

19 

20 /*@ 

21 @ public normaLbehavior 

22 @ ensures \result => exam + bonus >= passingGrade; 

23 @ ensures \result ==> (\forall int x; 0 <= x &fc x < 10; labs [x] ) ; 

24 @ assignable \nothing; 

25 @*/ 

26 boolean passed () { 

27 boolean enoughPoints = computeGrade() >= passingGrade; 

28 boolean allLabsDone = true; 

29 for (int i = 0; i < 10; i++) { 

30 allLabsDone = allLabsDone &fc labs [ i ]; 

31 } 

32 return enoughPoints &fc allLabsDone; 

33 } 

34 } 
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Listing 3.1: Implementation of the class StudentRecord 

As an example scenario for advantageous proof reuse we want to consider the 
StudentRecord class shown in Listing 3.1 This class represents results of a student’s par- 
ticipation in an arbitrary university course and provides functionality to determine, whether 
he or she has passed the course. 

A course is considered to be successfully completed (method passedO), if all the labs 
were done [^.nd the performance at the exam was satisfactory. The latter can be improved 
by the bonus (computeGrade), for which two different practices have been established. One 
approach, presented in Listing [T2| says that bonus is simply added to the exam result uncon¬ 
ditionally, the other, shown in Listing |3~3[ places a restriction, that bonus can only be used to 
improve the exam grade, if the exam itself was passed, i.e., the obtained grade is >= 4. Thus, 
we get two versions of the StudentRecord class, which only differ in the implementation of 
the computeGrade () method. 


class StudentRecord { 

{...} // Fields as in Listing 3.1 

class StudentRecord { 

/*@ 

{...} // Fields as in Listing 

@ public normal behavior 

3.1 

@ requires bonus >= 0; 

/*@ 

@ ensures (exam>= passingGrade) 

@ public normaLbehavior 

==> \result = exam + bonus; 

@ requires bonus >= 0; 

@ ensures (exam < passingGrade) 

@ ensures \result 

==> \result = exam; 

= exam + bonus; 

@ assignable \nothing; 

@ assignable \nothing; 

@*/ 

@*/ 

int computeGrade(){ 

int computeGrade(){ 

if (exam>= passingGrade) { 

return exam + bonus; 

return exam + bonus; 

} 

} else { 

return exam; 

j / 

boolean passed () {...} 

}} 

} 

/*@ ... 

Listing 3.2: Version 1 

boolean passed () {...} 

} 

Listing 3.3: Version 2 


Figure 3.1: Two alternative implementations of the method computeGrade () 


As we can observe, method passedO has a call to method computeGrade() in¬ 
side its body. An important characteristic of this example is that not only the imple¬ 
mentation of method computeGrade () is different in the two presented versions of the 
StudentRecord class, but also its specification. If only the first were the case, the exist¬ 
ing useMethodContract, as introduced in Section 2.2.3 (Definition 2.6), would provide the 
desired level of abstraction from the implementation, but in the given scenario it fails. Let 
us assume that upon arrival to this call during symbolic execution of method passedO, the 


1 Please note, that for our example the length of the array labs is irrelevant. In the proof for the passedO 
method the loop is handled by the looplnvariant rule and, as a short study has sown, using fixed length has 
no significant influence over the structure of the proof. The loop annotation can be found in Appendix. 
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call is handled by the useMethodContract rule. This makes any subsequent proof steps po¬ 
tentially specific to the concrete information provided by the computeGradeQ contract, for 
example that the computeGrade () method from Version 1 (Listing 3.2) does not modify any 
location. Thus, the rest of the proof of the correctness of method passed () from Version 1 
could not be reused to prove the correctness of the same method passed () from Version 2 
(Listing |3.3[ ), even though their implementations are identical. To further enhance the prob¬ 
lem, we point out, that the difference in modifies clauses of the computeGrade () contracts 
propagates the change in the modifies clause of the passed contract. 

A solution to this problem was proposed by Hahnle, Schafer and Bubel |HSB13| under 
the name of abstract method calls. Its main idea is to postpone any first-order logic reasoning 
based directly on the information from the used method contract to the latest possible stage, 
thus enlarging the reusable part of the proof. To achieve this a proof operates on placeholders 
standing for pre- and postconditions of used contracts until at least the end of symbolic execu¬ 
tion, instead of using their actual content. A contract defined with placeholders received the 
name abstract method contract , while its components are referred to as abstract precondition 
and abstract postcondition or abstract requires clause and abstract ensures clause. 

However, at the proposed in [ HSB13J form an abstract contract is subject to a serious 
limitation, namely the fact that the assignable clause cannot be abstractly defined. As it was 
illustrated by our example, the modifies clauses are not less likely to be affected by change of 
method implementation the pre- and postconditions are. The recent changes in the modeling 
of heap [Weillj in Java Card DL has made it possible to lift this restriction. Moreover, in the 
verification context supporting class invariants (such as KeY system), which are implicitly 
added to pre- and postconditions of all class methods, it is essential to also bring them to an 
abstract form. 

In the following two sections we define an abstract method contract in terms of JML and 
Java Card DL, addressing the named two issues by introducing an abstract assignable clause 
to an abstract contract and completing it with an abstract class invariant. 


3.2 Extending the JML Specification Language 

This section presents syntactical extensions introduced to JML to support the definition of 
abstract method contracts and abstract class invariants. Within the method contract our 
focus lies on requires, ensures and assignable clauses, that is why for simplicity reasons 
we only address the definition of an abstract contract for specifying normal behavior. 


3.2.1 Abstract method contract 


Listing 3.4 presents a template with which an abstract method contract for the normal 
behavior can be specified in JML. This template contains two parts: 

• declaration of clauses (lines 2-4) 

• definition of clauses (lines 5-7) 


We consider the requires, ensures and assignable clauses of the contract to be completely 
desugared , meaning that all of the specifications usually implicitly added to the contract 
by the JML syntactic sugar (like a clause assignable \nothing for a method annotated 
with the keywords pure) are explicitly formalized in the clauses themselves (except for class 
invariants). 


@ <v i sib i 1 i t y modifier> normaLbehavior 
@ requires.abs R; 
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@ ensures.abs E; 

4 @ assignable.abs A; 

5 @ def R = cboolean JML Expression>; 

6 @ def E = cboolean JML Expression>; 

7 @ def A = <store—ref list >; 

Listing 3.4: Template for an abstract method contract 


Declaration of clauses. In this part the keywords requires_abs, ensures_abs and 

assignable_abs are used to declare placeholders for requires, ensures and assignable clauses 
correspondingly. These placeholders are unique symbols, representing, in case of a requires 
and ensures clauses, a boolean JML expression and in case of an assignable clause - a set of 
locations. Their semantics with respect to the correctness of a method remain unchanged from 
that of a concrete method contract. So, for instance, in the above form of an abstract contract, 
the placeholder P stays for the precondition of the method, the placeholder E stays for the 
postcondition of the method and the placeholder A stays for the list of assignable locations 
of the method. Moreover, as in a concrete method contract, several placeholders for requires 
clauses may be declared, which is interpreted exactly as several requires clauses appearing 
in one contract (the same holds for placeholders for ensures and assignable clauses). When 
an abstract contract is translated into the Java Card DL, the placeholders are interpreted as 
predicates or functions of the same name, with functions having the return type LocSet (see 
Definition 3.1). 

Definition of clauses. The second part consists of an arbitrary number of definition 
clauses. Those are used to provide concrete instantiations to the placeholders declared in the 
first part. A definition clause starts with the keyword def, followed by the placeholder symbol 
to be defined and its definition. Note that the definition must correspond to the ’’type” of 
the placeholder it defines. For a placeholder declared with the keyword requires_abs or 
ensures abs it is a boolean JML expression, identical to those appearing after requires 
and ensures keywords in a concrete contract. For a placeholder declared with the keyword 
assignable abs it is a list of store-ref expressions or one of the keywords \everything, 
\nothing. The definition clauses are translated into the Java Card DL as rewrite rules, 


which will be explained in further details in Section 3.3 


3.2.2 Abstract invariant 


1 

2 


The idea pioneered on method contracts can be without any obstacles transferred onto class 
invariants. As seen in Listing 3.5, a template for an abstract invariant also consists of two 
parts: placeholders are declared with the keyword invariant_abs and defined with the 
keyword def. As usually, several placeholders can be declared and defined, in which case 
they will be joined by conjunction. 


@ visibility modifier> invariant_abs env; 

@ def env = <boolean JML Expressions-; 

Listing 3.5: Template for an abstract invariant 


In accordance to the usual semantics of class invariants, placeholders standing for invariants 
are added to pre- and postconditions of the method contract by conjunction, whenever this 
contract is used. 


3.2.3 Example 


On the example of the earlier introduced StudentRecord class, we show in Listing 3.6 how 
a class can be annotated with abstract contracts and invariants. 
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1 class StudentRecordj 

2 {...}// Fields as in Listing 3.1 

3 

4 //@ public invariant abs envl; 

5 //@ def envl = exam >= 0 bonus >= 0 &fc passingGrade >= 0; 

6 //@ public invariant _abs env2; 

7 //@ def env2 = labs.length = 10; 

8 

9 1 

10 @ public normaLbehavior 

11 @ requires.abs computeGradeR; 

12 @ ensures.abs computeGradeE; 

13 @ assign a 1) 1 e _a b s computeGradeA; 

14 @ def computeGradeR = bonus >= 0; 

is @ def computeGradeE = \result = exam + bonus; 

16 @ def computeGradeA = \ nothing; 

17 @*/ 

is int computeGrade(){ 

19 return exam + bonus; 

20 } 

21 

22 /=t@ 

23 @ public normaLbehavior 

24 @ requires.abs passedR; 

25 @ ensures_abs passedEl; 

26 @ ensures_abs passedE2; 

27 @ assign a 1) 1 o _a 1) s passedA; 

28 @ def passedR = true; 

29 @ def passedEl = \result ==> exam + bonus >= passingGrade; 

30 @ def passedE2 = \result ==> (\forall int x; 0 <= x &fc x < 10; labs [x]); 

31 @ def passedA = \nothing; 

32 @*/ 

33 boolean passed () { 

34 boolean enoughPoints = computeGrade() >= passingGrade; 

35 boolean allLabsDone = true; 

36 

37 for (int i = 0; i < 10; i++) { 

38 allLabsDone = allLabsDone &fc labs [ i ]; 

39 } 

40 return enoughPoints allLabsDone; 

41 } 

42 } 

Listing 3.6: Abstractly annotated StudentRecord class, Version 1 


3.3 Abstract method call in Java Card DL 

In this section we give the Java Card DL representation of abstract JML specifications intro¬ 
duced earlier. Definitions in this section apply to contracts of the methods (not constructors), 
that are neither static nor void. Extending them to cover these alternatives is straightforward. 

3.3.1 Placeholder 

Definition 3.1 (Placeholder). Let C G T be a Java Card class and let in. be a method declared 
in this class with parameters types t\ ... r n G T and a return type r G T. A placeholder is an 
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uninterpreted predicate or a function symbol of one of the following four types: 

• Requires placeholder is a predicate R(Heap, C,t\ ... r n ) £ P, which depends on the heap 
at invocation time, the receiver object and the parameters of the method. 

• Ensures placeholder is a predicate E(Heap, Heap , C,t,t\ ... r n ) £ P, which depends on 
the heap at the method’s final state (first argument), the heap at invocation time (second 
argument), the receiver object, the result value and the parameters of the method. 

• Assignable placeholder is a function A(Heap,C,r\.. .r n ) £ F of type LocSet, which 
depends on the heap at invocation time, the receiver object and the parameters of the 
method. 

• Invariant placeholder is a predicate I(Heap, C ) £ P, which depends on the current heap 
and the object for which the invariant should hold (for example, the receiver object of 
the method). 

We define placeholders as functions or predicates of multiple parameters to avoid faulty 
simplifications performed over them by Java Card DL calculus rules. The list of parameters 
on which the placeholder depends is defined following the nature of the specification the 
placeholder stands for. In the concrete requires clause and modifies clause it is possible to 
refer to the current heap (which is the heap at invocation time), the receiver object or the 
parameters of the method. In the ensures clause in addition to the current heap (which is 
now the heap in the method’s final state), the receiver object and the parameters, one can 
refer to the heap at pre-state or the result value. In the invariants only the program variables 
representing the current heap and the receiver object of the method are accessible. 

The keyword with which the placeholder is declared defines its type. For example, 
the declaration ensures_abs computeGradeE (line 12) from the specification of method 
computeGradeQ from Listing [376] is translated into the ensures placeholder 

boolean computeGradeE (Heap, Heap, StudentRecord , boolean) 

where given the program variables heap, heap pre , self and res are used to refer to the 
current heap, heap at pre-state, its receiver object and its return value respectively in the 
specifications of the method, the placeholder parameters would be instantiated as follows 

computeGradeE (heap, heap pre , self, res) 
when they appear in the clauses of the abstract method contract. 


3.3.2 Invariant 


Using the invariant placeholder, we can give definition to an abstract invariant. 


Definition 3.2 (Abstract invariant). Let C £ T be a Java Card class. Let heap be a global 
program variable used to refer to the current heap. An abstract invariant of the class C is a 
tupel 

(I, self, defi) 


that consists of 


• a unique invariant placeholder I(Heap, C ) for class C; 

• a unique program variable self declared for this class invariant to refer to the object 
of the class. 

• a term defj of type boolean which specifies the semantics of I and that can make use of 
the two variables heap and self 
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3.3.3 Abstract method contract 


Further making use of other types of placeholders, we can build the abstract clauses for the 
abstract method contract: 


Definition 3.3 (Abstract clauses). The abstract preconditions pre a , the abstract postcon¬ 
ditions post 0, and the abstract modifies clauses mod a are built according to the following 
grammar: 


pre a 

:= R 

I A pre a pre a 

A pre a 

post a 

:= E A I \ E A post a 

I A post a 

mod a 

:= A 

mod 0, U mod a 



where R, E, A and I are atomic formulas with a requires, ensures, assignable or invariant 
placeholder as top level symbol. 


This definition shows what kind of restrictions we place on abstract clauses. An abstract 
precondition should contain at least one requires placeholder and optionally a number of in¬ 
variant placeholders joined by conjunction. An abstract postcondition should contain at least 
one ensures placeholder and at least one invariant placeholder, also joined by conjunction. 
An abstract modifies clause contains at least one assignable placeholder. 

As follows from Definition 3.1 of placeholders, the abstract clauses are, in case of an 
abstract precondition and an abstract postcondition, the non-rigid terms of type boolean 
and, in case of an abstract modifies clause, the non-rigid terms of type LocSet. 

Now we can define an abstract method contract. This definition applies to contracts that 
do not allow for exceptional termination. 


Definition 3.4 (Abstract method contract). Let C E T be a Java Card class and let m be 
a method declared in this class with parameters types t\ ... r n E T and a return type r E T. 
Let heap E PV be a global program variable used to refer to the current heap. An abstract 
method contract for a method m is a tupel 


( PVars , Plhs, pre a , postf orm , mod a , term, Defs ) 


consisting of 


• a set of unique program variables PVars = {heap pre , self, res, exc, ai,...,a n } 
declared for the method m to refer to the heap at pre-state, the receiver object, the 
return value, the exception thrown by the method and the method parameters in its 
specifications. 

• a set of placeholders Plhs 

• an abstract precondition pre a 

• a postcondition post^ lorm = post a A (exc = null), where post a is an abstract poscondition 

• an abstract modifies clause mod a 

• a termination modifier term = {partial, total 

• a set Defs of pairs ( P, def P ) with a Java Card DL term def p of type boolean or LocSet 
for each placeholder P E Plhs. A term def p specifies semantics of P and can make use 
of variables from the set PVars 


The abstract clauses pre a , post a , and mod a are constructed according to the Definition 3.3 


from placeholders belonging to the set Plhs. This set contains requires, ensures and assignable 
placeholders declared for the particular method m and the invariant placeholders declared for 
the class C. This set must contain at least one placeholder of each type. The parameters of 
the placeholders are instantiated with program variables from the set PVars in the following 
manner: 
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• Requires placeholder - /?(heap, self, ai,..., a n ) 

• Ensures placeholder - E( heap, heap pre , self, res, ai,...,a n ) 

• Assignable placeholder - A( heap pre , self, ai,..., a„) 

• Invariant placeholder - /(heap, self) 

The program variable exc represents an exception thrown by the method, or null, if no 
exception is thrown. A boolean term def p defining the semantics of a requires placeholder 
can make use of the program variables heap, self, ai,..., a n . A boolean term def p defining 
the semantics of an ensures placeholder can additionally make use of the program variables 
heap pre and res. A term def p of type LocSet defining the semantics of a modifies placeholder 
can feature the program variables heap pre , self, ai,..., a„. A boolean term def p defining 
the semantics of an invariant placeholder can make use of the program variables heap and 
self 


3.3.4 Example 

To illustrate the definition of the abstract method contract we provide a translation of the 


JML specification of the method computeGrade () (lines 9 - 17) from the Listing 3.6 
Java Card DL logic. The abstract contract is a tupel 

( PVars , Plhs, pre a , post a norm , mod a , term, Defs) 


into 


consisting of 


PVars 

Plhs 

pre a 


post 


a 

norm 


mod a 

term 

Defs 


{heap pre , self, res, exc} 

{computeGradeR, computeGradeE, computeGrade A, envl, env2} 
computeGradeR( heap, self) 

A envl (heap, self)A env2 (heap, self) 
computeGradeE ( heap, heap pre , self, res) 

A envl (heap, self)A env2 (heap, self) 

\exc = null 

computeGradeA(hea.p pre , self) 
total 

}( computeGradeR, def cornpuLeGra.de a )■ (computeGradeE, def computeGradeE)i 
(computeGradeA, def computeGradeA ), (envl, def envl ), (env2, def env2 )} 


where 


def computeGradeR Self .bonus > 0 

def computeGradeE = res = self .exam + self .bonus 


def ComputeGradeA ~ 


def envl = self .exam >= 0 A self .bonus >= 
def env2 = self. labs, length = 10 


0 A self .passingGrade >= 0 


The terms def - result from the translation of JML expression appearing after the equality 
sign in the definition clauses into the Java Card DL logic. 
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3.3.5 Using Abstract Method Contracts 

The advantage of our definition of an abstract contract is that it can be used exactly as a 
concrete contract by an unmodified version of the useMethodContract rule. It guarantees 
the soundness of our abstract approach, provided the calculus using concrete contracts was 
sound. 

T ==> {u}{w}(pre), A 

T =>- {u}{rc}{heap pre = heap}{u}(posf -> [r = res; uj\(/>, A 

r =► M[ r = o.m(pi,...p n ); lo \ 4 >, A 

where w = (self := o || p ( := p\ || ... || p n := p n ) and v = (heap := 
anonf heap, mod, h!) || res := a). 

The schema variables pre and post are substituted by the components pre a and post^ orm 
of an abstract method contract. The abstract modifies clause mod a appears in the anonymi¬ 
sation update in place of mod. The Java Card DL formulas with placeholders resulting from 
the premisses of the useMethodContract rule can be simplified by the calculus rules in the 
same way as normal ones. Among others, the symbolic execution of the programs in the 
modalities may be continued, as well as separation of the proof goals and even closure of 
some of them. However, it is impossible to close the goals that rely on the information that 
would otherwise be provided by the concrete clauses of a method contract. Furthermore, 
the anonymisation of the heap with an abstract modifies clause mod a can be compared to 
the full anonymisation of the heap until the placeholders in mod a are expanded with their 
definitions. It can be explained by showing the exact semantics of the select operation on 
a small example from the proof using an abstract contract of the computeGrade () method. 
Let the term 

select(anon( heap, computeGradeA( heap pre , self ),h'), o, f) 
be part of an open goal. Then it can be simplified as follows: 

if (o, /) € computeGradeA( heap pre , self) then (select(h', o, /)) else (select(heap, o, /)) 

The if (o, f) G computeGradeA(heap pre , self) part cannot be resolved, because the set of 
assignable locations is represented by the placeholder. It is semantically equivalent to the 
situation, when the select operation returns the value of o.f from the fresh heap hi. 

The correctness proof for method m, which uses only abstract method contracts of method 
m itself and of all other methods that m invokes, is independent from the concrete specifications 
of these methods, that is, from the definitions given to placeholders. We refer to it as an 
abstract proof or partial proof. To prove that method m adheres to its concrete specification 
we have to expand the placeholders with their definitions. For this, every pair of the set Defs 
is translated into a rewrite rule, which is added in the calculus as an axiom. For example, a 
rewrite rule corresponding to the pair (computeGradeE, def computeGradeE ) from the abstract 
contract of the computeGrade () method has the following form: 

computeGrade(sv-heap, sv-heap pre , svself, sv-res ) 

sv-res = (select (sv-heap, svself, exam) + select (sv-heap, svself, bonus)) 

where svJieap, sv-heap pre , svself, svses are schema variables and symbols exam and bonus 
are constant functions of type Field. 

Before the expansion of the definitions takes place, we save the partial proof of method m. 
As long as the implementation of method m and the abstract clauses of the method contracts 
used in m have not changed, it can be loaded and reused to prove correctness of programs that 
have alternative concrete specification to the one we started with. More on the flexibility 
that abstract contracts offer is said in the next paragraph. 
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Flexibility of abstract method contracts Let there exist a partial proof for a method m 
that makes use of an abstract contract of the method n. Let’s assume we wish to change the 
behavior of the method n and probably even of the class it belongs to. What are we allowed 
to alternate in the implementation and specifications of our program so that the existing 
partial proof could still be reused in the new version? The answer to this question is given 
by the following list. 

• We can change the implementation of the method n. 

• We can redefine placeholders both of the method n and the method m, thus completely 
changing the essence of their specifications. 

However, there are some aspects on which the partial proof is solidly based and that cannot 
be changed without making it non-reusable: 

• The number, the types and the names of placeholders featured in all used method 
contracts 

• Signatures of the methods m and n 

• Type of the behavior of the methods m and n (normal or exceptional). 

Nevertheless, even with these restrictions, the abstract method call approach offers a high 
level of flexibility that is exceptionally valuable when working on either several version of one 
program at a time or undertaking unexpected changes to already verified programs. 
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Chapter 4 

Implementation 


As part of this thesis, we have extended the KeY verification system to support abstract 
method calls. The main tasks were to implement the automatic translation of abstract 
method contracts from JML specifications into the KeY logic and to provide the basic interface 
necessary for the workflow involving abstract method contracts, i.e construction, saving and 
reuse of a partial proof. Our implementation is based on the KeY system version 2.1. In 
this chapter we describe in details the changes to the source code that were required. We 
start in Section 4.1 by giving a stepwise explanation of how a Java program is verified in 
KeY in a general case and what parts of the KeY architecture are responsible for each of the 
steps. In Section 4.2 we give a conceptual overview of our design of abstract method contracts 
and abstract invariants in the KeY system. In Sections |4.3| - 14.6| we closely follow the steps 
described in Section 4.1 and provide information on how we have extended or modified the 
implementation of the KeY system to integrate the support of abstract method contracts and 
invariants. 


4.1 Verifying with KeY 

In this section we consider a typical user story supported by KeY system and describe which 
steps are taken to accomplish this task and how they are managed by the KeY system. 

Let’s assume that a user has implemented a Java program, has annotated it with JML 
and wishes to prove the correctness of program’s methods with regard to the provided spec¬ 
ifications. He loads the source files and as the first step, the Java source code is analyzed, 
which is handled by the package j ava. At this point the classes, their fields and methods are 
extracted and registered as such, the type hierarchy is extended. 

At the next step, the JML specifications are extracted, which is handled by the pack¬ 
age speclang. The main responsibility of the JMLSpecExtractor class is to extract either 
class level specifications (mainly class invariants) for a given class or method level specifi¬ 
cations (mainly method contracts) for a given method. For this it first calls the preparser 
which is defined by the grammar KeYJMLPreParser. g. Its main task is to recognize differ¬ 
ent types of JML annotations and translate them into corresponding textual representations 
(class TextualJMLConstruct). For example, a method contract returned by the preparser is 
represented by an object of the class TextualJMLSpecCase and its constituents (i.e. clauses, 
behavior modifies) are kept in this object individually as strings. 

After that, with help of the classes JMLSpecFactory and the JMLTranslator, the given 
textual constructs are transformed into specification elements (class Specif icationElement) 
- the internal representation of JML specifications in KeY. The class JMLTranslator which 
makes use of the parser defined by the grammar jmlparser.g is responsible for translating 
textual JML expressions into correct terms (class Term) and the class JMLSpecFactory is 
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responsible for the correct construction of specification elements. For example, a method 
contract is represented by the class FunctionalOperationContract and class invariants are 
represented by the class ClassAxiom. All specification elements are stored in an instance of 
the Specif icationRepository class. 

In case of method contracts the class JMLSpecExtractor performs several preparatory 
steps on textual constructs before handing them over to the JMLSpecFactory. It means that 
based on the information already available at this time (characteristics of a program method, 
behavior type of a contract) it resolves the sugaring of JML and adds implicit specifications to 
the contract. Among others these are implicit non-null conditions for all method parameters, 
invariants of the class and default versions of omitted clauses. 

This concludes the translation and at the next step the user is presented with the list 
of available contracts to prove. When one of the contracts is chosen to be proven, the class 
Problemlnitializer builds a proof obligation from it. Most of the preparatory work here is 
done by the class AbstractOperationPO (the prefix Abstract- in the name refers to this class 
being abstract and has no connection to abstract contracts or abstract method calls) that 
prepares the program method, pre- and postcondition, declares necessary program variables 
and registers proof specific rules, for example relevant class invariants. 

After the problem is initialized the user can attempt to prove it. The KeY system allows 
for interactive or automated construction of proofs. Strategy for the automated proof search is 
defined in the class JavaCardDLStrategy, where every rule set is assigned with the cost for its 
application. The behavior of this basic search strategy can be modified with macros that are 
designed for more specific search patterns. For example, the Finish Symbolic Execution 
macro puts priority on the symbolic execution of program in modalities and stops the search 
the moment the proof has no modalities left in the goals. 

At any stage during the proof search or after it is possible to save the current state of 
the proof to the .proof file, which is managed by the class Proof Saver. The .proof file 
contains the name of the contract, the path to the java source file from which the given 
contract originated, the settings in which its proof was constructed and the tree of rule 
applications. To load the proof the KeY system first translates the the provided java source 
file, then finds the right contract, constructs a corresponding proof obligation and repeats 
the listed rule applications on it. 

4.2 Implementation vs Definition 

In this section we discuss the differences between our formal definitions of abstract invariants 
and method calls and their actual implementation. 

First of all, even though we have provided the definition of abstract invariants in a form 
that completely resembles the approach used to define abstract contracts, the realization of 
the first in the KeY system is completely different. Every class is assigned with the model 
field inv representing its invariant. The JML invariants written by the user for one class are 
combined and translated into a represent clause for the class’ inv model field. The model fields 
are used in contracts to denote the invariant in pre- and postcondition and when required, 
they are substituted by their representation through the application of a useClassAxiom rule. 
Postponing the application of this rule has the same effect as postponing the application 
of placeholder expansions. This design contributes to our motivation behind the abstract 
method call approach and because it was present in the implementation of the KeY system 
before the start of our work, it has saved us the additional effort. 

In contrast to our definition, the implementation of abstract method calls allows for the 
use of mixed contracts. It means that not necessarily all clauses have to be abstract, instead 
the user himself chooses which clauses should be used abstractly by declaring appropriate 
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placeholders and giving definitions to them. Such an approach is advantageous in cases, when 
parts of the specification are expected to stay the same in different program versions, because 
as we later show in Chapter [5j full abstraction may lead to a significant increase of the proof 
size. Its drawback is, that an additional level of control is required from the user, because 
any omitted or implicitly implied by the JML sugaring features are interpreted in a concrete 
way. For example, if no requires clause or requires placeholder is provided, the contract will 
be completed with a concrete requires true precondition. 


4.3 Translation 


The preparser recognizes the strings that declare placeholders (for example requires abs R) 
and stores them in an instance of the TextualJMLSpecCase together with requires, ensures or 
assignable clauses, depending on the keyword. The definition clauses strings are also stored 
in an instance of Textual JMLSpecCase, but in a separate container. 

The parser deals with declaration of placeholders by creating a function or predicate 
according to Definition 3.1 registering it in a namespace, instantiating its parameters 
with correct program variables and returning it as a term to the SpecFactory. These 
terms are used by SpecFactory to build clauses and subsequently to form an object of 
FunctionalOperationContract class. Translated method contracts are stored in an instance 
of the Specif icationRepository class. 

For every definition clause the parser creates an instance of the AbstractContract- 
Definition class. It consists of a placeholder with instantiated parameters (field 
def inedSymbol) and the term which defines it (held definition). It is checked during trans¬ 
lation that types of the placeholder and its definition match. The definition term results 
from the translation of a JML expression. The instances of AbstractContractDef inition 
class are also stored in an instance of the Specif icationRepository class. 

Overall, our changes were focused in the preparser and parser. In addition to that, we call 
to the translation of AbstractContractDef initions inside the extractMethodSpecs(. . .) 
method of the JMLSpecExtractor class. But apart from that, no changes where done to the 
way JMLSpecExtractor or JMLSpecFactory handle the translation of method contracts. 


4.4 Rule Base 

The next step at which the modifications were required is the initialization of a proof 
obligation. As mentioned in Chapter [3j according to our model the definitions of place¬ 
holders are integrated into KeY as calculus rules or, to be more exact, as rewrite taclets. 
These are built from the instances of the class AbstractContractDef inition using the 
TaclteGenerator (see AbstractContractDef inition. toTaclet(...)). All taclets cre¬ 
ated from placeholder definitions belong to the rule set "expand.def" and carry the names 
"expand_def _placeholderName". In the heuristic of the JavaCardDLStrategy they have the 
application cost of —5700, which puts them right after most basic rules of propositional 
logic (not, andLeft, orRight) and before any other simplification, splitting or java rules in 
the priority list. This is done to ensure that during a normal automated proof search they 
were applied as soon as possible. Placeholder definition taclets are added to the JavaCardDL 
calculus as axioms, which means that their application does not have to be justified. 

The taclets for expansion of placeholders are loaded during the initialization of 
a proof obligation. More exactly, it happens in the readProblemO method of the 
AbstractOperationPO class, besides the loading of class axioms. 
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4.5 Construction of a Partial Proof 


By the time a user starts the construction of a proof for a chosen contract, the taclets for 
expansion of placeholders are already added to the rule base and available for interactive 
application. Moreover, calling the KeY auto pilot will trigger their application and lead to a 
construction of a full concrete proof. To ensure, that an automated construction of a partial 
proof is possible, we have implemented a strategy macro under the name Finish Abstract 
Proof. It serves as an additional filter between the standard strategy proposal of the next rule 
to be applied and its actual application on the goal. To serve our needs, this macro filters out 
the rules for the expansion of placeholders and for the usage of class invariants by setting their 
cost to infinity in the method computeCost (. . .) of the class FinishAbstractProofMacro. 
In any other sense the normal heuristic is used as defined by the JavaCardDLStrategy class. 
In particular, the work of the Finish Abstract Proof stops when no other rules can be 
applied, after which it is the right time to save the proof. 

It has to be noted, that other macros or strategies were not modified, which means that 
during construction of the partial proof their usage should be avoided. Otherwise, they might 
use axioms and placeholder expansion rules which will break the idea behind the partial proof. 
Another aspect worth mentioning is that the standard KeY’s automated proof search strategy 
applied on a goal with placeholders (with expansion taclets turned off by the macro) tends 
to perform too many unnecessary proof splits trying to ’’guess” the value of placeholders or 
objects on the heap after anonymization. The best results in avoiding this can be achieved 
by turning off the proof splitting in the JavaDL options during the use of Finish Abstract 
Proof macro. 


4.6 Saving and Loading a Partial Proof 


Caching and reusing the partial proof is the main point of our approach and necessary mod¬ 
ifications to the KeY system had to be made. 

For the caching of the partial proof we have decided to use the existing functionality of 
the KeY, namely its output format for the proofs. The form of the .proof file remains as 
described in Section 4.1 Saving of the proof can be done at any moment, but it makes sense 


to do it right after the Finish Abstract Proof macro stops, as it indicates, that no further 
simplifications can be done. 

For the loading of the proof we reuse a lot of KeY existing functionality, mainly presented 
in the Def aultProblemLoader class. Loading of the partial proof repeats the same steps as 
required for the normal loading of the proof, however, the path to the java source is taken 
not from the .proof file, but from the proof obligation for which the partial proof has to be 
loaded. This way, the newly constructed proof obligation is identical to the one that the user 
wants to prove, it contains the same taclets for the expansion of placeholders, but the rules 
applied to it are taken from the .proof file. Full replay of the cached proof on the new proof 
obligation is also advantageous as an additional check is made, whether the partial proof is 
compatible with the new proof obligation. 

The loading of the proof can be done by using the menu item Reuse proof at the stage, 
when a proof obligation, for which we wish to reuse the partial proof, is opened and selected in 
the main window. After the replay of the partial proof the user can continue with construction 
of the concrete proof, using any of the macros and strategies available in the KeY system. 
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Chapter 5 

Evaluation 


The objective of this chapter is to empirically evaluate the benefits in terms of the proof reuse 
offered by our implementation of abstract contracts in KeY. Our conjecture is that abstract 
contracts shall provide reasonable savings in the proof effort. 

We conducted this empirical evaluation on two case study programs, where each of the 
programs come in several versions. These program versions have a common top-level interface 
and differ in the implementation as well in the concrete specification of the called sub-routines. 
The abstract specification of each sub-routine, however, stays the same. 

This chapter is structured as follows. In Section 5.1 we describe implementation and 
specification of our case study programs. In Section Y2 we describe our experimental setup 
and elaborate on the nature of the undertaken experiments. Section [5 . 3| present the empirical 


results that we have obtained. In Section 5.4 we interpret these results and derive a conclusion 
on the benefits offered by our implementation of abstract contracts. 


5.1 Case Study Programs 

5.1.1 Account case study 


Our first case study is based on the example introduced in |TSAH12] and is a program 
consisting of two classes, Account and Transaction. It is implemented in five versions, of 


which we describe the first basic one (Listing 5.1) in details and afterwards give the short 
description of differences between the versions. 


Version 1 The class Account represents a simple bank account, with method boolean 
update (int x) for deposit or credit operation (depending on the sign of the parameter 
x) on the balance of the account. The reverse operation is offered by method boolean 
undoUpdate(int x). Both methods signal whether the operation was successful with the 
boolean return value. In the first basic version these methods apply the change on the field 
balance unconditionally and always return true, which is also reflected in their contracts. 


1 public class Account { 

2 int balance = 0; 

3 boolean lock = false ; 

4 

5 public normal behavior 

6 @ ensures (balance = \old(balance) + x) &&; \result; 

7 @ assignable balance; 

8 @f=/ 

9 boolean update (int x) { 


31 









10 balance = balance + x; 

11 return true; 

12 } 

13 /*@ public normal behavior 

14 @ ensures (balance = \old( balance) — x) &&; \result; 

is @ assignable balance; 

16 @1= / 

17 boolean undoUpdate(int x) { 

is balance = balance — x; 

19 return true; 

20 } 

21 /*@ public normaLbehavior 

22 @ ensures \result = this, lock; 

23 @f=/ 

24 boolean pure isLocked() { 

25 return lock; 

26 } 

27 } 

28 

29 public class Transaction { 

30 public normal behavior 

31 @ requires destination != null &fc source != null; 

32 @ requires source != destination; 

33 @ ensures \result ==> (\old(destination.balance) + amount = destination.balance); 

34 @ ensures \result => (\old(source. balance) — amount = source. balance); 

35 @ assignable \everything; 

36 @f=/ 

37 public boolean transfer (Account source, Account destination, int amount) { 

38 if (source.balance < 0) amount = —1; 

39 if (destination.isLockedQ) amount = —1; 

40 if (source.isLockedQ) amount = —1; 

41 

42 int take; 

43 int give; 

44 if (amount != —1) { take = amount * —1; give = amount;} 

45 

46 if (amount <= 0) { 

47 return false; 

48 } 

49 if (!source.update(take)) { 

so return false; 

51 } 

52 if (! destination .update(give)) { 

53 source. undoUpdate(take); 

54 return false; 

55 } 

56 return true; 

57 } 

58 } 

Listing 5.1: Implementation and specification of the classes Account and Transfer (Ver. 1) 

The account can be locked to prevent any operation over it, which is reflected by 
the field boolean lock. The state of the account lock is returned by the method 
boolean isLockedO, which behavior is not carried among the versions. 

The methods of the class Account are used by method boolean transfer 
(Account source, Account destination, int amount) of the class Transaction to per- 
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form a transfer between two accounts. It takes the amount of money from source and pays 
it to destination. It performs a number of pre-checks to ensure that the transaction will 
be successful before actually performing the transfer. For instance, transfer operation is 
unsuccessful (and returns false) if either of the following conditions is met: 

• balance of the source account is negative 

• one of the accounts is locked 

• the transfer amount equals zero or is negative 

• one of the update operations is negative. 

Otherwise the method transfers money between the accounts and returns true. 

The contract of method transfer!. . .) in the basic version of the program specifies only 
the outcome of the successful transfer, more concretely, it should be proven that if the return 
value is true, then the new balances of accounts equal their old balances (before the call) 
plus (for destination)/minus (for source) the value of the parameter amount. 

Version 2 In the second version, the implementation of the classes remains unchanged. 
However, we simplify the contract of method transfer to such that it only has to be proven 
that if the transferable amount is negative, then the method returns false, which models 
one of the possible behaviors of this method. 

Version 3 In comparison with the first version of this program, the third version contains 
the notion of an overdraft limit (represented by the static field int OVERDRAFT_LIMIT of 
the class Account). An additional test is implemented in the methods update!. • •) and 
undoUpdate!. . .), to ensure, that the overdraft limit of the account is not exceeded as the 
result of the operation. When the operation is not possible, the method returns false. 

On the side of the specification this modification of the code is reflected as follows. In 
the new ensures clauses of methods update!. . .) and undoUpdate!. . .) we perform a case 
distinction on whether the returned boolean result is true or false. In case the result is true, 
the specification coincides with the specification of the first version of our program. In case 
the result is false, the specification claims that the balance stays unchanged. The specification 
of the transfer!. . .) method is undisturbed by the overdraft limit test and repeats the one 
from Version 1. 

Version 4 The fourth version is a further extension of the third one. In addition to the 
overdraft limit, the account is restricted by the daily withdrawal limit, which sets the bound 
on the amount of money that can be withdrawn from the account in one day. The limit is 
represented by the static field DAILY .LIMIT and the amount of money that was withdrawn in 
one day is accumulated in the field int withdraw of the class Account. The implementation 
of methods update!. • .) and undoUpdate!. . .) is extended to perform an additional limit 
test and to maintain the amount of money withdrawn in one day. 

On the side of the specification this modification of the code required an adaptation 
of the ensure clauses of the methods update!. • •) and undoUpdate!. • •)• In the new en¬ 
sures clauses of the methods update!. . .) and undoUpdate!. . .) we specify the state of the 
withdraw field after a successful or unsuccessful operation exactly the same way as it was 
done for the balance field in the third version. The specification of the transfer!. • •) 
method is undisturbed by the daily withdrawal limit test and repeats the one from Version 
1. 
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Version 5 The fifth version is an alternative extension of the third one. In addition to the 
overdraft limit of the account, an update operation is now charged with a fee (represented 
by the static field int FEE of the class Account). It is subtracted from the balance during a 
successful update (...) operation and restored, when the method undoUpdate (...) is called. 

On the side of the specification this modification of the code required an adaptation of 
the ensure clauses of the methods update (...) and undoUpdate (...). In the parts of the 
ensures clauses that specify the state of the balance after a successful operation, the charge 
and restoration of the fee is taken into account. The specification of the transfer!. • •) 
method is adapted to accommodate the fee charge. Its postcondition is weakened from 
giving the exact values of the source and destination accounts after a successful transfer, to 
setting their lower bound. 

The source code for all five versions of the Account case study can be found in the Section 
A.2 of the Appendix. 


5.1.2 StudentRecord case study 

The second case study for our evaluation is already introduced in Chapter 3 as the running 
example class StudentRecord. The method passed!) is the top-level method of this program, 
which we verify in our experiments. This method calls the sub-routine computeGradeO. 
For the experiments we have additionally implemented a third simpler version of the class, 


presented in Listing 5.2 


class StudentRecord { 

// exam result 
int exam; 

// minimum grade necessary to pass the exam 
int passingGrade ; 

// completed labs 

boolean)] labs = new boolean [10]; 

//@ public invariant exam >= 0 &fc passingGrade >= 0; 

//@ public invariant labs.length = 10 ; 

/*@ 

@ public normal behavior 
@ requires true; 

@ ensures \result = exam; 

@ assignable \nothing; 

int computeGrade() { 
return exam; 

} 

@ public normal behavior 

@ ensures \result => exam>= passingGrade; 

@ ensures \result => (\forall int x; 0 <= x &fc x < 10 ; labs[x]); 

@ assignable \nothing; 

boolean passed ( ) { 

boolean enoughPoints = computeGrade() >= passingGrade; 
boolean allLabsDone = true; 
for (int i = 0 ; i < 10 ; i++) { 
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allLabsDone = allLabsDone &fc labs [ i ]; 


} 

return enoughPoints &fc allLabsDone; 

} 


Listing 5.2: Implementation and specification of the class StudentRecord (Ver. 3) 

As we see, in this version the class has no notion of the bonus at all, which influences the 
invariants of the class, the specification and implementation of the sub-routine, and the 
specification of the top-level method. 

Not surprisingly, the proofs of method passed() in the three different versions expose 
the same pattern. All of them start with a comparably small portion to reflect the se¬ 
mantics of the first two assignments, which closely relies on the specification of the method 
computeGradeQ. Afterwards, the major part of the proof deals with establishing the cor¬ 
rectness of the loop invariant, which we provide as a JML annotation beforehand. In the end, 
the rest of the method is analyzed in the state after the loop and subsequently the correctness 
of the postcondition is established. 

The source code for all three versions of the StudentRecord case study can be found in 
Section |A.1| of the Appendix. 
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5.2 Setup and Experiments 

In order to assess the the benefits offered by our implementation of abstract contracts in KeY 
we conduct two experiment series which we describe below. Both series use two case study 
programs (including all their corresponding versions) which we presented in Section 

We conducted all our experiments on a Mac laptop with Intel Core i5 2.4 GHz processor 
and 4 GB RAM running the Mac OS X 10.7.5 and Java 7. We used our modification of the 
KeY system, which was based on the version 2.1 and implemented as defined in Chapter [4j 

5.2.1 Experiment Series 1 

The goal of this experiment series is to empirically analyze how much of the proof efforts can 
be saved by using our implementation of abstract contracts. 

Originally, for each of the described case study programs we wanted to conduct two exper¬ 
iments: the first with completely abstract specification, and the second with concrete specifi¬ 
cations. Completely abstract specifications follow the concept defined in Listing 3.4. We state 
the abstract precondition by requires_abs R, the abstract postcondition by ensures_abs 
E, and the abstract modifies clause by assignable_abs A. Concrete specification directly 
state the desired pre- and postconditions as well the modifies clause. We presented the 
essentials of the concrete specifications for our two case study programs in Section |5.1[ 

However, after running several trial experiments and gaining some experience we envi¬ 
sioned the third way of giving specifications to which we refer as partially abstract specifica¬ 
tions. They differ from the abstract specification in one aspect: the modifies clause is given 
concretely. Stating the modifies clause concretely, like e.g., assignable foo, allows KeY to 
keep the information about all variables except the variable foo after the application of the 
method contract and thus reduces the required verification effort. 

Thus, for each of the described case study programs we conduct three experiments which 
differ in three kinds of specifications we use: completely abstract specification, partially 
abstract specification, and concrete specifications. 

In each experiment with completely abstract specification and partially abstract speci¬ 
fication as the first step we derive a partial proof. For this, we load one of the versions of 
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each program (we use the first version) and turn off the proof splitting option in the KeY’s 
settings. We run the automated verification process in an abstract mode (using the Finish 
abstract proof macro), and by this obtain the partial proof that we then save for the future 
reuse while verifying the remaining versions of each program. By examining the KeY statis¬ 
tics dialog, we note down the number of proof nodes as well as the number of branches in 
the partial proof. Next, we consecutively load each version of the programs to be verified, 
load the saved partial proof, and run the normal automated verification process. Similarly, 
we examine and note down the number of proof nodes as well as the number of branches in 
each of these proofs. 

In each experiment with concrete specifications we directly run the normal verification 
process on each program version and note down the number of proof nodes as well as the 
number of branches in each of the obtained proofs. 

5.2.2 Experiment Series 2 

The goal of this experiment series is to empirically analyze how big are the parts of the proofs 
in our case studies that can be done by symbolic execution. In this experiment series we use 
only concrete specifications. For each of the case study program and for each of their version 
we run the following experiment. 

After loading a program into KeY we, firstly, run symbolic execution until possible and 
note down the number of proof steps. Secondly, we close the resulting first-order goals with 
the auto pilot and note down the overall number of proof steps. 


5.3 Results of Experiments 


5.3.1 Experiment Series 1 


The results of the experiment series 1 are given in Table 5.1 and Table |5i2] for case studies 1 
and 2, respectively. The rows of the tables, except for the last ones, correspond to different 
program versions. Columns II and V present the number of proof steps (alternatively called 
nodes) in partial proofs, i.e., proof parts that have to be done once for all version of the 
program due to the usage of abstract contracts. Columns III and VI present the number of 
proof steps required to finish the partial proof for every particular version of the program. 
Columns IV and VII present the number of proof steps in complete proofs, computed by 
summing up the number of steps in the partial proof with the number of steps for the rest of 
the proof. Column VIII presents the number of proof steps in a full proof that uses concrete 
specifications. The number of branches in the proofs is given in brackets. 

The row “Total” gives the total number of proof steps needed to verify the complete 
programs of each case study, i.e., all versions of the programs. For the experiments using 
concrete specifications the total equals the sum of the number of steps for the different 
versions, i.e., total = Y27=if u ^h with n being the number of program versions and fullj 
being the number of steps in the full proof for the version i. In case of the experiments 
using partially or completely abstract specifications, we compute the total of rest part of 
the proofs for different versions and add the size of the partial proof only once, as it can be 
reused between program versions. The formula for this computation has the following form: 
total = (X)r = i resti) +partial, where n is the number of program versions, resti is the number 
of steps in the rest part of the proof for the version i and partial is the number of steps in 
the partial proof. 
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Completely abstract 

Partially Abstract 

Concrete 

I. 

II. 

III. 

IV. 

V. 

VI. 

VII. 

VIII. 


Partial 

Rest 

Full 

Partial 

Rest 

Full 

Full 

vl 

1390 (55) 

676 (2) 

2066 (57) 

1408 (55) 

457 (0) 

1865 (55) 

1035 (63) 

v2 

492 (2) 

1882 (57) 

315 (0) 

1723 (55) 

972 (63) 

v3 

1045 (4) 

2435 (59) 

488 (0) 

1896 (55) 

1352 (68) 

v4 

1329 (4) 

2719 (59) 

567 (0) 

1975 (55) 

1461 (68) 

v5 

1349 (6) 

2739 (61) 

619 (2) 

2027 (57) 

1601 (69) 

Total 

6281 


3854 


6421 


Table 5.1: Results of experiment series 1 for case study 1 (account example) 



Completely abstract 

Partially Abstract 

Concrete 


Partial 

Rest 

Full 

Partial 

Rest 

Full 

Full 

I. 

II. 

III. 

IV. 

V. 

VI. 

VII. 

VIII. 

vl 

514 (9) 

677 (16) 

1191 (25) 

519 (9) 

626 (16) 

1145 (25) 

919 (21) 

v2 

1292 (31) 

1806 (40) 

1263 (31) 

1782 (40) 

1419 (36) 

v3 

495 (15) 

1009 (24) 

418 (15) 

937 (24) 

904 (22) 

Total 

2978 


2826 


3242 


Table 5.2: Results of experiment series 1 for case study 2 (student example) 


5.3.2 Experiment Series 2 


The results of the experiment series 2 are given in Table 5.3 and Table 5.4 for case studies 1 
and 2, respectively. The rows of the tables correspond to different program versions. Columns 

II present the number of proof step in the symbolic execution parts of the proofs. Columns 

III present the number of proof steps in complete proofs, where in brackets the number of 
branches of the proofs are given. Columns IV give the percentage of the symbolic execution 
part of the proof in complete proofs. They are obtained by dividing the numbers in Columns 
III by the numbers in Columns II. 



Symbolic execution 

Full proof 

Ratio 

I. 

II. 

III. 

IV. 

vl 

842 (53) 

1041 (63) 

81% 

v2 

818 (53) 

981 (63) 

83% 

v3 

1037 (56) 

1361 (68) 

76% 

v4 

1147 (56) 

1471 (68) 

78% 

v5 

1141 (56) 

1655 (68) 

69% 


Table 5.3: Results of experiment series 2 for case study 1 (account example) 


5.4 Interpretation of Experimental Results 

We carefully investigated the results of the two experiment series that we described so far 
in this chapter. This allowed us to derive six observations about the concept of abstract 
contracts which we present in this section. 
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Symbolic execution 

Full proof 

Ratio 

I. 

II. 

III. 

IV. 

vl 

442 (11) 

955 (21) 

46% 

v2 

494 (11) 

1451 (36) 

34% 

v3 

410 (11) 

853 (21) 

48% 


Table 5.4: Results of experiment series 2 for case study 2 (student example) 


5.4.1 Observation 1 


Deploying the concept of abstract contracts allows one to reuse up to 82% of the 
proof. Partially abstract specifications, on average, allow to reuse 63% of the proof. 
Completely abstract specifications, on average, allow to reuse 53%> of the proof. 


This observation follows from analyzing Tables 5.1 and 5.2 Figures 5.1 and 5.2 depict 


the size of the proofs and percentages of proof reuse in our two case studies. Figures on the 
left correspond to partially abstract specifications, whereas figures on the right correspond to 
completely abstract specifications. The gray area corresponds to the partial proof that had 
to be constructed only once for all versions of the program. The green area depicts additional 
steps that were required to finish the full proof for each version. The percentage of reuse 
shows to what amount of the full proof the partial proof corresponds to, i.e how much of the 
full proof was done in single step by loading the pre-saved partial proof. The percentages are 
computed by dividing the size of the partial proof by the size of the full proof per program 
version. 

It turns out that completely abstract specifications offer quantitatively worse proof reuse 
outcome than partially abstract specifications. However, they give more flexibility in alter¬ 
nation of the contracts content. As discussed in Section [5.2[ partially abstract specifications 
differ from completely abstract ones in that the modifies clause is given concretely in the 
former. This allows KeY to keep the information about the heap at locations that are not 
listed in the modifies clause after the application of the method contract rule and as a con¬ 
sequence, close several branches in the partial proof itself. However, they restrict the user 
from changing the value of assignable clause in subsequent versions of the program. 



(a) Partially abstract specification (b) Completely abstract specification 

Figure 5.1: Proof reuse in case study 1 (account example) 
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(a) Partially abstract specification (b) Completely abstract specification 


Figure 5.2: 


Proof reuse in case study 2 


(student example) 
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5.4.2 Observation 2 


The size of the proof reuse offered by abstract contracts is somewhat proportional to 
the size of the symbolic execution parts of proofs. 


This observation follows from comparing result tables of our first experiment series (Ta¬ 
bles 5.1 and 5.2) to the results tables of the second experiment series (Tables [573] and |54| . We 
explored the relationship between the percentage of proof reuse offered by abstract contracts, 
both in their partially abstract and completely abstract versions, and the percentage of the 
proof steps that are done by means of the symbolic execution when verifying the same pro¬ 
grams using concrete specifications. We depicted these percentages for our two case studies 
in Figure 5.3 In this figure, the red and the green curves corresponds to proof reuse which 


result from deploying partially and completely abstract specifications, respectively, whereas 
the blue curves correspond to the size of the symbolic execution part in proofs of the programs 
using concrete specifications. 

It turns out that the behavior of the blue, red, and green curves is rather similar. From 
this, one can conclude that the best proof reuse is achieved for programs with complex 
implementations but simple specifications. 




vl 

Concrete 


-Partially abstract 


v3 

Abstract 


(b) Student example 

Figure 5.3: Percentage of reused proof (green and red) compared to the percentage of symbolic 
execution (blue) 
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5.4.3 Observation 3 


Deploying the concept of abstract contracts always increases the overall proof size 
per each program version. The size of such proofs involving completely abstract 
specifications is always larger than those involving partially abstract specifications. 


This observation follows from considering the number of proof steps needed to verify 
each individual version of a program deploying concrete, partially abstract, and completely 
abstract specifications. Figure [5~4] depicts these numbers for our two case studies. For each 
individual program version, we consider the number of required proof steps when verifying 
the program version against its concrete specification as 100%. Having this, using partially 
abstract specifications increases the proof effort for individual program versions by 39% on 
average. Using completely abstract specifications increases the proof effort for individual 
program versions by 62% on average. 

However as a partial proof can be reused between different program versions this ad¬ 
ditional proof effort will, as we will see in Observations 5 and 6, be compensated when 
considering the effort required for verification of all program versions together. 



Concrete ■ Partially abstract ■ Abstract 







Concrete ■ Partially abstract ■Abstract 


(a) Account example (b) Student example 

Figure 5.4: Proof size per version in nodes 
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5.4.4 Observation 4 


Deploying the concept of abstract contracts almost does not increase the number of 
branches in a proof per each program version. 


This observation follows from considering the number of branches in full proofs for each 
individual version of a program built using concrete, partially abstract and completely ab¬ 
stract specifications. We depicted these numbers for both our case studies in Figure |5.5 


This observation means that the overall number of first-order goals that have to be closed to 
verify a program version is not affected by the deployment of abstract specifications. This is a 
great advantage, because the first-order goals can be delegated to SMT solvers, which usually 
offer a significant speed-up in closing such goals compared to the KeY System. Assuming the 
development of interface between KeY and SMT solvers, e.g. Z3, there is an expectation of 
rest parts of the proof taking insignificant effort in terms of time. 



(a) Account example (b) Student example 

Figure 5.5: Number of branches in proof per version 
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5.4.5 Observation 5 


Deploying the concept of abstract contracts, both in partially and completely abstract 
flavors, does not enlarges the overall proof size per program, i.e., for all program 
versions together. The overall proof size per program is smaller for partially abstract 
contracts than for completely abstract contracts. 


We compared the overall proof effort that is required for verification of each of our two 
case studies using concrete, partially abstract, and completely abstract specifications. The 
result of this comparison is depicted in Figure 5.6 Clearly, using partially abstract as well 


as fully abstract specifications does not increase the overall proof effort for verification of all 
versions of each of the programs together. In fact, both partially and completely abstract 
specifications offered a decrease in the number of overall required proof steps, whereas for 
the abstract specifications this decrease is rather marginal and for the partially abstract 
specifications, as the account case study suggests, can be significant. 



Figure 5.6: Total proof size in nodes for all versions per example 
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5.4.6 Observation 6 


In order to derive the last observation we came up with an additional measurement notion 
which we call the amortized proof effort. Because the partial proof is reused between versions 
of a program it make sense to distribute its size between all versions in order to assess the 
reuse benefit in evaluation of the proof effort per version. The amortized proof effort is 
measured in the number of proof steps per version. For proofs using completely abstract and 


partially abstract specifications it is computed by the formula APEi = pa ™ ai + resti , where 


partial 
n 

n is the number of program versions, partial is the number of steps in the partial proof and 
resti is the number of steps in the rest of the proof for the version i. For proofs using concrete 
specifications it equals the full size of the proof, i.e., APEi = fulli, where fillip is the number 
of steps in the full proof for the version i. We present these numbers in Table [57a] and Table 


5.6 for case studies 1 and 2 respectively. 



Completely abstract 

Partially abstract 

Concrete 

vl 

954 

738 

1035 

v2 

770 

596 

972 

v3 

1323 

769 

1352 

v4 

1607 

848 

1461 

v5 

1627 

900 

1601 


Table 5.5: Amortized proof effort per version (account example) 



Completely abstract 

Partially abstract 

Concrete 

vl 

848 

799 

919 

v2 

1463 

1436 

1419 

v3 

666 

591 

904 


Table 5.6: Amortized proof effort per version (student example) 


Thus, it allowed us to derive the following observation. 


The amortized proof effort of abstract contracts is always not larger than the one 
of concrete contracts. It is considerably smaller for partially abstract specifications 
and is comparable for fully abstract specifications. 


This observation follows from comparing the size of the amortized proof effort for each in¬ 
dividual version of a program deploying concrete, partially abstract, and completely abstract 
specifications. Figure [a 7| depicts these numbers for our two case studies. Clearly, distribut¬ 
ing the size of a partial proof among versions shows the gain of proof reuse, especially for 
the Account example. This allows us to make an conjecture, that the benefit of deploying 
abstract contracts increases for the programs with higher number of versions. 
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Concrete ■ Partially abstract ■ Abstract 


(a) Account example (b) Student example 

Figure 5.7: Amortized proof effort per version in nodes 


5.5 Additional Experiments 

The programs on which we have conducted our experiments so far have one drawback in the 
context of our work: the list of locations assignable by the subroutine methods was stable 
among different versions of the programs. On the one hand it has allowed us to investigate 
and compare the use of both completely and partially abstract contracts. On the other 
hand, it did not fully covered the achievements of this work, namely the introduction of fully 
abstract contract with abstract assignable clauses. Moreover, the frame conditions that had 
to be proven for top-level methods were almost trivial. For example, the assignable clause 
for the method transf er (. . .) in the Account case study was specified as \everything. It 
meant that little proof effort was necessary after the expansion of assignable placeholders to 
close the goals. 

To get the full picture of our work we decided to evaluate additional case studies that 
address these issues. In this section we proceed as follows. First of all we describe imple¬ 
mentation and specification of our case study programs. Then we describe our experimental 
setup and present the empirical results that we have obtained. Finally, we interpret these 
results and derive a conclusion. 


5.5.1 Case Studies 


Our new case studies are based on the Account example introduced in Section 5.1 The 


method transfer!. . .) of the class Transaction now not only performs the transfer of 
money between the accounts, but also writes the information about this transaction into the 
log. 


The class Log is implemented in three versions. All of them model the log as an array 
int [] logRecord of integers and have a public method void add(int bal) and a private 
method void rotateLogO. The first one rotates the log to get a new empty slot and writes 
information to it, while the second one implements the rotation. There version of Log class 
differ in a way the log is rotated to get a new empty slot. 


Ring In this version the log is modeled as a ring. New data is written into the next empty 
location of an array and if the array is full, the process starts from the beginning, overwriting 
the existing data. Hence, the assignable clause of method add has the following form: 
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//@ assignable logRecord[(last + 1) % logRecord.length], last; 
where last is a pointer to the last written location of the array. 

Empty In this version new data is written into the next empty location of an array and if 
the array is full, all of the data it contains is deleted and the process starts at the beginning. 
Hence, the assignable clause of method add has the following form: 

//@ assignable logRecord[*] , last; 

where last is a pointer to the last written location of the array. 

Replace In this version new data is written into the next empty location of an array and if 
the array is full, it is discarded completely and the new empty array is created, in which the 
process starts at the beginning. Hence, the assignable clause of method add has the following 
form: 


//@ assignable logRecord, last, logRecord[last + 1] ; 


where last is a pointer to the last written location of the array. 

The code for all three version of the Log class can be found in Section A.3 of the Appendix. 

For the integration of class Log into the Account example we have chosen its most basic 
first version. An instance of class Log is included as a field into the Transaction class. 
Method add(. . .) is called in the transfer! • ■ ■) method. Because the invocation of method 
add (...) has a strong effect on the current heap we have decided to investigate two possible 
situations. Once it is called at the very beginning of the method transfer!. . .). It models 
that the information about the transaction is always written into the log independently of the 
fact, whether the transfer of money actually occurs. For the proof search it means, that all 
branches caused by the symbolic execution have to operate on the heap anonymised by the 
application of the contract of the method add!. . .). We refer to this program as Begin case 
study. In the second case study the method add (...) is called in one branch only, namely 
only after the transfer of money actually takes place. It means, that the major part of the 
proof is unaffected by the anonymisation of the heap by the application of the add (...) 
contract. We refer to this program as End case study. 

The frame condition for the method transfer! • • •) is much stricter, than it was in the 
previous experiments. Its assignable clause explicitly lists all modifiable locations, which 
directly copies the locations listed in the contract of a corresponding add!. . .) plus the 
balance fields of accounts taken as parameters. 


5.5.2 Setup and Results 

For each of the case studies we have provided completely abstract specifications and con¬ 
crete specifications. The setup for the experiments using these two types of specifications 
repeats the one described in Section |in2] For the proofs constructed using completely abstract 


specifications we note down the size of the partial proof and the full proof. For the proofs 
constructed using concrete specifications we note done the number of steps performed during 
symbolic execution and the size of the full proof. The size of the proof is expressed in terms 
of nodes and branches (given in parenthesis). 


The results for the Begin and End case studies are presented in the Table 5.7 and the 


Table 5.8 respectively. The rows of the tables correspond to different versions of the Log 
class. Columns V. show the ratio of the size of the partial proof to the size of the full proof 
when using abstract specifications, that is the percentage of the reusable proof part in the 
full proof. Columns VIII. give the ratio of symbolic execution part of the proof to the full 


46 






proof when using concrete specifications. Row “Total” shows the aggregated proof effort for 
all versions. It is computed using the formula defined in Section [5.2| 



Completely abstract 

Concrete 


Partial 

Full 

Ratio 

Symbolic execution 

Full 

Ratio 

I. 

II. 

IV. 

V. 

VI. 

VII. 

VIII. 

Ring 

1403 (58) 

24012 (448) 

6 % 

1449 (56) 

25303 (278) 

6 % 

Empty 

10974 (301) 

13% 

1380 (56) 

5777 (123) 

24% 

Replace 

17060 (517) 

8 % 

1346 (56) 

16666 (485) 

8 % 

Total 

49240 

47746 


Table 5.7: Results for Account+Log, Begin case study 



Completely abstract 

Concrete 


Partial 

Full 

Ratio 

Symbolic execution 

Full 

Ratio 

I. 

II. 

IV. 

V 

VI. 

VII. 

VIII. 

Ring 

1583 (58) 

4489 (111) 

35% 

1206 (56) 

2692 (86) 

45% 

Empty 

4003 (106) 

40% 

1115 (56) 

2141 (79) 

52% 

Replace 

4454 (114) 

36% 

1118 (56) 

2666 (91) 

42% 

Total 

9780 

7499 


Table 5.8: Results for Account+Log, End case study 


5.5.3 Interpretation 

The results of additional experiments give mixed impression. First of all, we notice that the 
reuse percentage has dropped dramatically to the average of 10% in the Begin example, while 
also falling under 40% in the End example. Secondly, we see that the aggregated proof effort 
required to verify all version of the program is no longer smaller when using abstract approach 
than when using concrete specification, which might be connected to the reuse percentage. 
Another interesting feature is that while the deployment of abstract contracts increases the 
proof effort pro program version compared to the concrete approach on average by 75% in 
the End case study, the Begin case study shows reverse pattern. Two program versions, Ring 
and Replace , experienced almost no increase at all. 

However, one of our previous observations got confirmed by the additional experiments. 
There exists a very strong correlation between the proof reuse percentage when using abstract 
specifications and the ratio between symbolic execution and complete proof when using con¬ 
crete specifications. This leads us to an assumption, that abstract contracts are less effective 
in terms of proof saving efforts in context of programs that have complex specification and 
lead to first-order goals that are difficult to prove. In proofs for such programs the symbolic 
execution part, which we aim to reuse, becomes insignificant comparing to the first-order 
reasoning part. The situation is further enhanced when the program method contains many 
conditional statements or method calls that split the proof. As a result, a lot of identical 
simplification steps have to be repeated in different branches, especially if the placeholders 
are replaced with their definitions only after all splits were done. This particular issue could 
be tacked by recognizing of similar goals for which the same proof steps can be applied. The 
use of placeholders can help here because they hide the complex details of first-order goals 
and similar patterns get more recognizable. 
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Chapter 6 

Related Work 


Since the release of the Java programming language in 1995, formal reasoning about correct¬ 
ness and security of Java programs attracted much attention by the scientific community and 
a lot of progress has been made. Below we list some of the important milestones in verifica¬ 
tion of Java programs achieved over the last two decades. First experiments in formalization 
and deductive verification of Java programs in the verification system PVS were done in 
the LOOP project | JvdBHvB98j . Huisman and Jacobs [HJOOl defined a set of Hoare logic 
rules for verifying Java programs in PVS, including the reasoning about abrupt termination. 
While these were experiments in mechanical interactive verification, Havelund and Press- 
burger [HPOOj proposed to apply the SPIN model checker for automatic verification of Java 
programs which were translated to the Promela language of SPIN with the Java PathFinder 
tool. Subsequent developments in the area went in the directions of making verification tools 
for Java more practical and applicable in the industrial context. This includes the start of 
the development of the KeY tool |ABB + 00 which is now ongoing for almost fifteen years 
and also has given the context for this thesis. Another tool with the similar goal is, for in¬ 
stance, the jStar tool [DP08i |. Beside tools that aim at formal functional verification of Java 
programs, there is a line of tools that specifically address static verification of the security of 
Java programs (e.g., [Mye99^ GH081 lL!?TT] ). 

Regarding the reuse of proofs in software verification, this topic has attracted attention 
already in the beginning of the 1990’s |RS93| and a number of different approaches has been 
explored since then. Felty and Howe FI 19 1 prototyped a theorem proving system that sup¬ 
ports generalization of tactic proofs by using rneta variables, and by that offers possibilities 
for proof reuse. Melis and Whittle [ MW99] investigate reasoning by analogy in the context 
of interactive theorem proving and suggested an approach how to reuse gathered problem 
solving experience in proof planning. Schairer and Hutter [SH02| explore how proofs evolve 
together with modifications of formal specifications of the software. They introduce a set of 
basic transformations for specifications which induce the corresponding transformations of 
the proofs. An incremental proof reuse mechanism based on similarity measure is proposed 
by Beckert and Klebanov |BK04j in the context of the KeY project. This mechanism allows 
to reuse proof steps even if the situation in the new proof is not identical to the existing 
template. Hutter and Autexier |HA05j discuss how to maintain the dependence between 
formal specifications and proofs in large formal software development projects by means of 
development graphs. For each modification, the effect in the development graph is com¬ 
puted such that only invalidated proofs have to be re-done. Bourke et al. |BDKK12j report 
on the challenges an the experience with proof reuse in two large-scale formal verification 
projects )AHL+08l IKEH+09J . Dovland, Johnsen, and Yu D.l V 121 introduce a set of allowed 
changes for evolution of object-oriented programs. In their approach, a proof context is 
constructed which keeps track of proof obligations for verified method contracts. Program 
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changes cause the proof context to be adapted so that the proof obligations that are still 
valid are preserved and new proof goals are created. 

Recently Hahnle, Schaefer, and Bubel HSB13 proposed the concept of abstract method 
contracts in order to facilitate proof reuse in software verification. This work is directly 
extended by the current thesis. 


49 




Chapter 7 


Conclusion and Future Work 


In this thesis, we presented the implementation and evaluation of the concept of abstract 
operational contracts [HBB13j within the KeY verification system. 

The implementation part of this thesis delivered three technical contributions. Firstly, we 
extended the set of specification forms that may be defined abstractly with abstract locations 
sets and abstract class invariants. We provided supporting formal definitions and extended 
the JML to cover abstract specifications. Secondly, we adapted the JavaDL logic for proper 
handling of abstract method calls. Thirdly, we adapted verification workflow of the KeY 
system to facilitate automatic reuse of proofs by clearly separating and caching reusable 
proof parts. We also implemented necessary changes to the graphical user interface and to 
the proof search strategies in the KeY system. 

In the evaluation part of this thesis we conducted several experiments in order to under¬ 
stand the benefits of the implementation of abstract contracts in a practical setup. This has 
revealed three main practical advantages of our implementation of abstract contracts. 

Better modularity. Abstract contracts offer a possibility to conduct a preliminary proof 
for a program even when no specification for this program is given, e.g., immediately 
right after the program has been written. This preliminary proof the can be reused 
during any proper verification of the program against any desired concrete specification. 

Better flexibility. Our implementation of abstract contracts allows the user to modify 
more aspects of specifications without breaking the partial proof. In particular, our 
implementation allows the user to modify not only pre- and postconditions, but also 
program invariants as well as assignable clauses. 

Non-increase in number of proof branches. Although using abstract contracts in¬ 
creases the total number of proof steps for the verification of a particular program ver¬ 
sion, it does not increase the number of proof branches. To this end, it looks promising 
to apply SMT solvers in order to discharge open first-order goals of the partial proofs. 

Moreover, during our practical evaluation of abstract contracts, we gathered a number 
of interesting insights on how the shape of specifications and of programs under verification 
affect the resulting number of proof steps. In the table below, we summarize these observation 
by classifying whether a particular aspect has more positive or more negative effect on the 
number of proof steps. 

Regarding the future work, among others, the two following directions offer themselves 
as meaningful candidates for an immediate follow-up to this thesis. 
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More positive 

More negative 

concrete assignable clause 

abstract assignable clause 

complex program & simple specifications 

simple program &; complex specifications 

long single execution path 

rich branching 


Increase of proof reuse. Due to the abstract contracts there is a certain number of 
the generated identical subgoals and, respectively, proof parts that can be handled 
in a more effective fashion. These identical subgoals appear when using the abstract 
contracts because, in contrast to using the concrete contracts, the KeY system first 
performs the split step and then the simplification steps. As a consequence there is a 
numebr of identical simplification steps generated. Search for and recognition of such 
proof parts is a promising direction for further increase of proof reuse. 

Integration of the approach. Our implementation of abstract contracts can be integrated 
in the background verification plugin for Eclipse in order to support software engineers 
with an efficient, on-the-fly verification. Here, partial proofs can be constructed and 
saved automatically while the software engineer develops a program. Furthermore, any 
brake of the proofs due to modifications done in the subroutines can be detected, and 
the respective partial proof can be loaded automatically before any concrete proof steps 
are performed. 
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Appendix A 


Appendix 

A.l Code of the StudentRecord example 

In this section of the appendix we provide the code of the StudentRecord example as it was 
used in our experiments from the Chapter Evaluation. For every version of the program we 
provide three Listings. 

• First listing corresponds to the experiments using concrete specification 

• Second listing corresponds to the experiments using partially abstract specification 

• Third listing corresponds to the experiments using completely abstract specification 

Please note, that in the listings of the second and the third category, we only show the 
specification of the methods and omit their implementation, as the latter does not change. 

A.1.1 Version 1 


class StudentRecord { 

// exam result 
int exam; 

// achieved bonus 
int bonus; 

// minimum grade necessary to pass the exam 
int passingGrade; 

// completed labs 

boolean[] labs = new boolean [10]; 

//@ public invariant exam >= 0 &fc bonus >= 0 &fc passingGrade >= 0 ; 

//@ public invariant labs.length = 10; 

@ public normaLbehavior 
@ requires bonus >= 0 ; 

@ ensures \result = exam + bonus; 

@ assignable \nothing; 

@*/ 

int computeGrade () { 

return exam + bonus; 

} 
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@ public normaLbehavior 

@ ensures \result ==> exam + bonus >= passingGrade; 

@ ensures \result ===> (\forall int x; 0 <= x &fc x < 10; labs[x]); 

@ assignable \nothing; 

@i=/ 

boolean passed ( ) { 

boolean enoughPoints = computeGrade() >= passingGrade; 
boolean allLabsDone = true; 

/*@ loop invariant 0 <= i &fc i <= 10 

(\forall int x; 0 <= x x < i ; 
allLabsDone => labs [x]); 

@ assignable allLabsDone; 

@ decreases 10 — i; 

@i=/ 

for (int i = 0; i < 10; i++) { 

allLabsDone = allLabsDone labs [ i ]; 

} 

return enoughPoints allLabsDone; 

} 

} _ 

Listing A.l: Concrete specification, Ver. 1, StudentRecord 


class StudentRecord { 

{ ... } // Fields as in the Listing A.l 

//@ public invariant exam >= 0 &fc bonus >= 0 &fc passingGrade >= 0 ; 

//@ public invariant labs.length = 10; 

/*@ 

@ public normal behavior 
@ requires_abs computeGradeR; 

@ ensures_abs computeGradeE; 

@ assignable \nothing; 

@ def computeGradeR = bonus >= 0; 

@ def computeGradeE = \result = exam + bonus; 

@i=/ 

int computeGrade ( ) { ... } 

/*@ 

@ public normal_behavior 
@ requires_abs passedR; 

@ ensures_abs passedEl ; 

@ ensures_abs passedE2 ; 

@ assignable \nothing; 

@ def passedR = true; 

@ def passedEl = \result ==> exam + bonus >= passingGrade; 

@ def passedE2 = \result ==> (\forall int x; 0 <= x &fe x < 10; labs [x] ); 

@i=/ 

boolean passed () { ... } 


Listing A.2: Partially abstract specification, Ver. 1, StudentRecord 


class StudentRecord { 

{ ... } // Fields as in the Listing A.l 

//@ public invariant exam >= 0 &fc bonus >= 0 &fc passingGrade >= 0; 

//@ public invariant labs.length = 10; 

/>i@ 
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@ public normaLbehavior 
@ requires_abs computeGradcR; 

@ ensures_abs computeGradeE; 

@ assignable_abs computeGradeA; 

@ def computeGradeR = bonus >= 0; 

@ def computeGradeE = \result = exam + bonus; 

@ def computeGradeA = \nothing; 

@*/ 

int computeGrade () { ... } 

/*@ 

@ public normaLbehaviour 
@ requires_abs passedR; 

@ ensures_abs passedEl; 

@ ensures_abs passedE2; 

@ assignable_abs passedA; 

@ def passedR = true; 

@ def passedEl = \result ==> exam + bonus >= passingGrade; 

@ def passedE2 = \result ==> (\forall int x; 0 <= x &&: x < 10; labs [x]); 
@ def passedA = \nothing; 

@*/ 

boolean passed () { ... } 


Listing A.3: Completely abstract specification, Ver. 1, StudentRecord 


A.1.2 Version 2 


class StudentRecord { 

// exam result 
int exam; 

// achieved bonus 
int bonus; 

// minimum grade necessary to pass the exam 
int passingGrade; 

// completed labs 

boolean[] labs = new boolean [10]; 

/ /@ public invariant exam >= 0 &fc bonus >= 0 &fc passingGrade >= 0; 

//@ public invariant labs.length = 10; 

/*@ 

@ public normaLbehavior 
@ requires bonus >= 0; 

@ ensures (exam>= passingGrade) ===> \result = exam + bonus; 

@ ensures (exam < passingGrade) ==> \result = exam; 

@ assignable \nothing; 

@*/ 

int computeGrade(){ 

if (exam>= passingGrade) { 
return exam + bonus; 

} else { 

return exam; 

}} 
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/*@ 

@ public normal_behavior 

@ ensures \result ===> exam + bonus >= passingGrade; 

@ ensures \result ==> (\forall int x; 0 <= x &fc x < 10; labs [x]); 

@ assignable \nothing; 

@i=/ 

boolean passed () { 

boolean enoughPoints = computeGradeQ >= passingGrade; 
boolean allLabsDone = true; 

/*@ loop_invariant 0 <= i &fc i <= 10 

(\forall int x; 0 <= x x < i; 
allLabsDone => labs [x]); 

@ assignable allLabsDone; 

@ decreases 10 — i; 

@i=/ 

for (int i = 0; i < 10; i++) { 

allLabsDone = allLabsDone labs [ i ]; 

} 

return enoughPoints allLabsDone; 

} 

} _ 

Listing A.4: Concrete specification, Ver. 2, StudentRecord 


class StudentRecord { 

{ ... } // Fields as in the Listing A.4 

//@ public invariant exam >= 0 &fe bonus >= 0 &fc passingGrade >= 0; 

//@ public invariant labs.length = 10; 

@ public normaLbehaviour 
@ requires_abs computeGradeR; 

@ ensures_abs computeGradeE; 

@ assignable \nothing; 

@ def computeGradeR = bonus >= 0; 

@ def computeGradeE = (exam >= passingGrade ==> \result = exam + bonus) 
Mz (exam < passingGrade =>\result = exam); 

@ 1 =/ 

int computeGradeQ{ ... } 

@ public normaLbehaviour 
@ requires_abs passedR; 

@ ensures_abs passedEl; 

@ ensures_abs passedE2; 

@ assignable \nothing; 

@ def passedR = true; 

@ def passedEl = \result => exam + bonus >= passingGrade; 

@ def passedE2 = \result => (\forall int x; 0 <= x Mz x < 10; labs [x]); 

@ 1 =/ 

boolean passed)) { ... } 


Listing A.5: Partially abstract specification, Ver. 2, StudentRecord 


class StudentRecord { 

{ ... } // Fields as in the Listing A.4 


//@ public invariant exam >= 0 &fc bonus >= 0 passingGrade >= 0; 

//@ public invariant labs.length = 10; 
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/#@ 

@ public normaLbehaviour 
@ requires_abs computeGradcR; 

@ ensures_abs computeGradeE; 

@ assignable _abs computeGradeA; 

@ def computeGradeR = bonus >= 0; 

@ def computeGradeE = (exam >= passingGrade ==> \result = exam + bonus) 
&&: (exam < passingGrade =>\result = exam); 

@ def computeGradeA = \nothing; 

@*/ 

int computeGrade(){ ... } 

/o@ 

@ public normaLbehaviour 
@ requires_abs passedR; 

@ ensures_abs passedEl; 

@ ensures_abs passedE2; 

@ assignable_abs passedA; 

@ def passedR = true; 

@ def passedEl = \result => exam + bonus >= passingGrade; 

@ def passedE2 = \result => (\forall int x; 0 <= x &&: x < 10; labs [x]); 
@ def passedA = \nothing; 

@*/ 

boolean passed)) { ... } 


Listing A.6: Completely abstract specification, Ver. 2, StudentRecord 


A.1.3 Version 3 


class StudentRecord { 

// exam result 
int exam; 

// miimnum grade necessary to pass the exam 
int passingGrade; 

// completed labs 

boolean)] labs = new boolean [10]; 

/ /@ public invariant exam >= 0 &fc passingGrade >= 0; 

//@ public invariant labs.length = 10; 

/*@ 

@ public normal behavior 
@ requires true; 

@ ensures \result = exam; 

@ assignable \nothing; 

@i=/ 

int computeGrade(){ 
return exam; 

} 


/»® 

@ public normal_behavior 

@ ensures \result ===> exam >= passingGrade; 
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@ ensures \result (\forall int x; 0 <= x &fc x < 10; labs[x]); 

@ assignable \nothing; 

@1=/ 

boolean passed () { 

boolean enoughPoints = computeGrade() >= passingGrade; 
boolean allLabsDone = true; 

/*@ loop_invariant 0 <= i <M: i <= 10 

(\forall int x; 0 <= x x < i; 
allLabsDone => labs [x]); 

@ assignable allLabsDone; 

@ decreases 10 — i; 

@i=/ 

for (int i = 0; i < 10; i++) { 

allLabsDone = allLabsDone labs [ i ]; 

} 

return enoughPoints allLabsDone; 

} 

} 


Listing A.7: Concrete specification, Ver. 3, StudentRecord 


class StudentRecord { 

{ ... } // Fields as in the Listing A. 7 

//@ public invariant exam >= 0 &fc passingGrade >= 0; 

//@ public invariant labs.length = 10; 

/*@ 

@ public normaLbehavior 
@ requires_abs computeGradeR; 

@ ensures_abs computeGradeE; 

@ assignable \nothing; 

@ def computeGradeR = true; 

@ def computeGradeE = \result = exam; 

@*/ 

int computeGrade(){ ... } 

@ public normal_behavior 
@ requires abs passedR; 

@ ensures_abs passedEl ; 

@ ensures_abs passedE2 ; 

@ assignable \nothing; 

@ def passedR = true; 

@ def passedEl = \result => exam>= passingGrade; 

@ def passedE2 = \result ==> (\forall int x; 0 <= x &&: x < 10; labs [x]); 

@i=/ 

boolean passed () { . . . } 


Listing A.8: Partially abstract specification, Ver. 3, StudentRecord 

class StudentRecord { 

{ ... } // Fields as in the Listing A. 7 

//@ public invariant exam >= 0 passingGrade >= 0 ; 

//@ public invariant labs.length = 10; 

/tpj public normaLbehavior 
@ requires_abs computeGradeR; 

@ ensures_abs computeGradeE; 

@ assignable_abs computeGradeA; 
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@ def computeGradeR = true; 

@ def computeGradeE = \result = exam; 

@ def computeGradeA = \nothing; 

@*/ 

int computeGrade(){ ... } 

/ *@ public normaLbehavior 
@ requires_abs passedR; 

@ ensures_abs passedEl; 

@ ensures_abs passedE2; 

@ assignable_abs passedA; 

@ def passedR = true; 

@ def passedEl = \result ==> exam>= passingGrade ; 

@ def passedE2 = \result ==> (\forall int x; 0 <= x &fc x < 10; labs [x] ); 
@ def passedA = \nothing; 

@*/ 

boolean passed () { . . . } 


Listing A.9: Completely abstract specification, Ver. 3, StudentRecord 


A.2 Code of the Account example 

In this section of the appendix we provide the code of the Account example as it was used in 
our experiments from the Chapter Evaluation. For every version of the program we provide 
its implementation and concrete specification. The partially abstract specification, as well 
is the the completely abstract specification are omitted, because they can be straitforwardly 
derived from concrete specification following the same principles, that where illustrated in 
the previous section. 

A.2.1 Version 1 


public class Account { 

/*@ accessible \inv:this.*; @)=/ 

int balance = 0; 

public boolean lock = false; 


A 

@ public normaLbehavior 

@ ensures (balance = \old(balance) + x) <Mr \result; 
@ assignable balance; 

@*/ 

boolean update(int x) { 
balance = balance + x; 

return true; 

} 

/*@ 

@ public normaLbehavior 

@ ensures (balance = \old( balance) — x) &&: \result; 
@ assignable balance ; 

@*/ 

boolean undoUpdate(int x) { 
balance = balance — x; 

return true; 
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/*@ 

@ public normal_behavior 
@ ensures \result = this . lock; 

@i=/ 

boolean /*@ pure @*/ isLocked() { 
return lock; 

} 

} 

public class Transaction { 

/*@ accessible \inv:this.*; @ 1 =/ 

public normal_behavior 

requires destination != null &fc source != null \ invariant_for (source) 

\invariant_for (destination); 
requires source != destination; 

ensures \result ===> (\old(destination. balance) + amount = destination . balance); 
ensures \result ===> (\old(source. balance) — amount = source. balance); 

assignable \everything; 

@i=/ 

public boolean transfer (Account source, Account destination, int amount) { 
if (source.balance < 0) amount = —1; 
if (destination.isLockedQ) amount = —1; 
if (source.isLockedQ) amount = —1; 

int take; 
int give; 

if (amount != —1) { take = amount * —1; give = amount;} 

if (amount <= 0) { 

return false; 

} 

if (! source .update (take)) { 

return false; 

} 

if (! destination . update(give)) { 
source. undoUpdate(take); 

return false; 

} 

return true; 

} 

} _ 

Listing A.10: Concrete specification, Ver. 1, Account and Transaction 


A.2.2 Version 2 


public class Account { 

/*@ accessible \inv:this.*; 

int balance = 0; 

public boolean lock = false; 

@ public normaLbehavior 
@ ensures \result; 

@ assignable balance; 

@i=/ 

boolean update) int x) { 
balance = balance + x; 
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return true; 

} 

/#@ 

@ public normal_behavior 
@ ensures \result; 

@ assignable balance ; 

@i=/ 

boolean undoUpdate(int x) { 
balance = balance — x; 

return true; 

} 

/*@ 

@ public normal behavior 
@ ensures \result = this . lock ; 

®i=/ 

boolean /*@ pure @*/ isLockedQ { 
return lock ; 

} 

} 

public class Transaction { 

/*@ accessible \inv:this.*; ©fc/ 

/ *@ public normalbehavior 

requires destination != null &fe source != null \invariant_for (source) 

&&: \invariant_for (destination ); 
requires source != destination; 

ensures true; 

ensures (amount <= 0) =5> !\ result; 
assignable \everything; 

@*/ 

public boolean transfer (Account source, Account destination, int amount) { 
if (source.balance < 0) amount = —1; 
if ( destination.isLockedQ ) amount = —1; 
if (source.isLockedQ ) amount = —1; 

int take; 
int give ; 

if (amount != —1) { take = amount * —1; give = amount;} 

if (amount <= 0) { 

return false; 

} 

if (! source .update(take)) { 

return false; 

} 

if (! destination . update(give)) { 
source. undoUpdate(take); 

return false; 

} 

return true; 

} 

} _ 

Listing A.11: Concrete specification, Ver. 2, Account and Transaction 
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A.2.3 Version 3 


public class Account { 

/*@ accessible \inv:this.*; @*/ 

final int OVEI01Al^_LEV'Jir = 0; 

//@ public invariant balance >= ()VIT IDT{Al■ TI ,I1\ HT: 

int balance = 0; 

public boolean lock = false; 

/#@ 

@ public normaLbehavior 

@ ensures (!\result => balance = \old( balance)) 

@ &fc (\result ==> balance = \old(balance) + x); 

@ assignable balance ; 

@*/ 

boolean update (int x) { 

int newBalance = balance + x; 
if (newBalance < OVERDR4ETTJM1T) 
return false; 
balance = newBalance; 
return true; 

} 

/*@ 

@ public normaLbehavior 

@ ensures (!\result => balance = \old( balance)) 

@ &fe (\result ==> balance = \old(balance) — x); 

@ assignable balance ; 

@*/ 

boolean undoUpdate(int x) { 

int newBalance = balance — x; 
if (newBalance < OVEBDlMETIiMir) 

return false; 

balance = newBalance; 

return true; 

} 

/*@ 

@ public normaLbehavior 
@ ensures \result = this . lock; 

@*/ 

boolean /*@ pure <0^= / isLockedQ { 
return lock ; 

} 

} 

public class Transaction { 

accessible \inv:this.*; @)=/ 

/*@ public normal_behavior 

requires destination != null &fc source != null &&; \invariant_for (source) 

&&: \invariant_for (destination ); 
requires source != destination ; 

ensures \result ==> (\old(destination. balance) + amount = destination . balance) ; 
ensures \result ==> (\old(source. balance) — amomit = source. balance) ; 

assignable \everything; 

®i=/ 

public boolean transfer (Account source, Account destination, int amount) { 
if (source.balance < 0) amount = —1; 
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if (destination.isLockedQ) amount = —1; 
if (source.isLockedQ) amount = —1; 

int take; 
int give; 

if (amount != —1) { take = amount * —1; give = amount;} 

if (amount <= 0) { 

return false; 

} 

if (!source.update(take)) { 

return false; 

} 

if (! destination .update(give)) { 
source. undoUpdate(take); 

return false; 

} 

return true; 

} 

} _ 

Listing A.12: Concrete specification, Ver. 3, Account and Transaction 


A.2.4 Version 4 


public class Account { 

/*@ accessible \inv:this.*; (§k/ 

final int OWRDRAFTHMir = 0; 
final static int DA1T ,Y TJMTT = —1000; 

//@ public invariant balance >= OVERDRAFT_LDVllT; 
int balance = 0; 

//@ invariant withdraw >= DAILYJJMTT; 
int withdraw = 0; 

public boolean lock = false; 

/*@ public normaLbehavior 

@ ensures (!\result ==> balance = \old(balance)) 
@ &fc (\result ==> balance === \old(balance) + x) 
@ &fc (!\result ===> withdraw = \old(withdraw)) 
@ &fc (\result ==> withdraw <= \old(withdraw)); 
@ assignable balance; 

@*/ 

boolean update) int x) { 

int newWithdraw = withdraw; 
if (x < 0) { 

newWithdraw += x; 
if (newWithdraw < DAILY JJMTT) 
return false; 

} 

int newBalance = balance + x; 
if (newBalance < OVERDRAFTIMT) 
return false; 
balance = newBalance; 
withdraw = newWithdraw; 
return true; 

} 
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/ *@ public normal_behavior 

@ ensures (!\result => balance = \old( balance)) 

@ &fc (\result ==> balance = \old(balance) — x) 

@ &fc (!\result ==> withdraw = \old(withdraw)) 

@ &fc (\result ==> withdraw >= \old (withdraw)); 

@ assignable balance; 

@i=/ 

boolean rmdoUpdate(int x) { 

int newWithdraw = withdraw; 
if (x < 0) { 

newWithdraw —= x; 
if (newWithdraw < DAILYJJMTT) 
return false; 

} 

int newBalance = balance — x; 
if (newBalance < OVERDR4ILriiMlT) 
return false; 
balance = newBalance; 
withdraw = newWithdraw; 

return true; 

} 

/o@ 

@ public normaLbehavior 
@ ensures \result = this . lock; 

@*/ 

boolean /*@ pure @*/ isLockedQ { 
return lock; 

} 

} 

public class Transaction { 

/*@ accessible \inv:this.*; @ 1 =/ 

/*@ public normaLbehavior 

requires destination != null &fc source != null &&; \ invariant_for (source) 
\invariant_for (destination); 
requires source != destination; 

ensures \result ===> (\old(destination. balance) + amount = destination . balance); 
ensures \result ==> (\old(source. balance) — amomit = source. balance); 

assignable \everything; 

@i=/ 

public boolean transfer (Account source, Account destination, int amount) { 
if (source.balance < 0) amount = —1; 
if (destination.isLockedQ) amount = —1; 
if (source.isLockedQ) amount = —1; 

int take; 
int give; 

if (amount != —1) { take = amomit * —1; give = amomit;} 

if (amomit <= 0) { 

return false; 

} 

if (! source .update (take)) { 

return false; 

} 

if (! destination . update(give)) { 
source. undoUpdate(take); 

return false; 

} 
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} 


return true; 


} _ 

Listing A.13: Concrete specification, Ver. 4, Account and Transaction 

A.2.5 Version 5 


public class Account { 

accessible \inv:this.*; (§&/ 

final int (AT.'RDltM'I' IJMI'I' — 0; 

final int FEE = 1; 

//@ public invariant balance >= OVERDIIAFTIIMIT; 

//@ public invariant FEE >= 0; 

int balance = 0; 

public boolean lock = false; 

/*@ public normaLbehavior 

@ ensures (!\result ==> balance = \old( balance)) 

@ &fc (\result ==> balance == \old(balance) + x — FEE); 
@ assignable balance ; 

@i=/ 

boolean update) int x) { 

int newBalance = balance + x — FEE; 
if (newBalance < OVEKDRAETJUM1T) 
return false; 
balance = newBalance; 
return true; 

} 

/*@ public normaLbehavior 

@ ensures (!\result ==> balance = \old( balance)) 

@ &fc (\result => balance = \old(balance) — x + FEE); 
@ assignable balance ; 

@i=/ 

boolean undoUpdate(int x) { 

int newBalance = balance — x + FEE; 
if (newBalance < OVEKDlL\FTIiMlT) 
return false; 
balance = newBalance; 
return true; 

} 

@ public normaLbehavior 
@ ensures \result = this . lock; 

@i=/ 

boolean /*@ pure @*/ isLockedQ { 
return lock ; 

} 

} 

public class Transaction { 

accessible \inv:this.*; <§A/ 

/*@ public normaLbehavior 
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requires destination != null &fc source != null &fc \ invariant_for (source) 

&fc \invariant_for (destination); 
requires source != destination; 

ensures \result ==> (\old(destination. balance) + amount >= destination . balance); 
ensures \result ==> (\old(source. balance) — amount >= source. balance); 

assignable \everything; 

@ 1 =/ 

public boolean transfer (Account source, Account destination, int amount) { 
if (source. balance < 0) amount = —1; 
if (destination.isLockedQ) amount = —1; 
if (source.isLockedQ) amount = —1; 

int take; 
int give; 

if (amount != —1) { take = amount * —1; give = amount;} 

if (amount <= 0) { 

return false; 

} 

if (! source .update(take)) { 

return false; 

} 

if (! destination . update(give)) { 
source. undoUpdate(take); 

return false; 

} 

return true; 

} 

} 

Listing A.14: Concrete specification, Ver. 5, Account and Transaction 


A.3 Code of the Log class 

In this section of the appendix we provide the code for the three versions of the Log class 
as it was used in our additional experiments in Chapter [5} For every version of the program 
we provide its implementation and concrete specification. The completely abstract specifi¬ 
cation can be straitforwardly derived from concrete specification and the partially abstract 
specification is not relevant, because the assignable clauses in this example differ among the 
versions. 

A.3.1 Ring 

public class Log { 

/*@ accessible \inv:this.*; &=/ 

//@ public invariant logRecord. length > 0; 
protected /*@ spec_public @*/ int [] logRecord; 

//@ public invariant last >= — 1 && last < logRecord. length; 

protected /*@ spec .public @*/ int last; 


public Log(int size) { 

this. logRecord = new int [ size ] ; 
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last = —1; 


} 

/*@ public normaLbehavior 
@ requires true; 

@ ensures (\result = (last = logRecord.length — 1 ? 0 : last + 1)); 

@ assignable \nothing; 

@*/ 

protected /*@ pure @*/ int rotateLog() { 
return (last + 1) \% logRecord. length; 

} 

/*@ public normal_behavior 
@ requires true; 

@ ensures (last = (\old(last) = logRecord. length — 1 ? 0 : \old(last) + 1)) && 
@ (logRecord [ last ] =bal); 

@ assignable logRecord [(last + 1) \% logRecord. length] , last; 

@*/ 

public void add(int bal) { 

last = rotateLog(); 

logRecord [ last ] = bal; 

} 

} _ 

Listing A. 15: Concrete specification, Ring Log 


A. 3.2 Empty 


public class Log { 

/*@ accessible \inv:this.*; @*/ 

//@ public invariant logRecord. length > 0; 
protected /*@ spec_public : '<i*/ int [ ] logRecord; 

/ /@ public invariant last >=— 1 last < logRecord. length; 

protected /*@ spec_public @*/ int last; 

public Log(int size) { 

this . logRecord = new int [ size ]; 
last = —1; 

} 

/*@ public normaLbehavior 
@ requires true; 

@ ensures (\result = ((logRecord. length—1 = last) ? 0 : last + 1)) && 

@ ((logRecord. length—1 = last) ==> 

@ (\forall int i; i>=0&&: i<logRecord.length; logRecord[i] =0)); 

@ assignable logRecord [ * ]; 

@*/ 

public int rotateLogQ { 

if (last = logRecord.length — 1) { 

// empty array 

/*@ loop_invariant 
@ i>=0&& i<=dogRecord.length &fe 

@ (\forall int j; j>=0&fej<i; logRecord[j] =0); 

@ decreases logRecord. length — i; 

@ assignable logRecord]*]; 

for (int i = 0; i<logRecord.length; i++) { 
logRecord [ i ] = 0; 
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} 

return 0; 

} else { 

return last + 1; 

} 

} 

/*@ public normaLbehavior 
@ requires true; 

@ ensures last = (\old(last) = logRecord. length — 1 ? 0 : \old(last) + 1) 
@ logRecord [ last ] = bal; 

©assignable logRecord]*], last; 

©!=/ 

public void add(int bal) { 

last = rotateLog(); 

logRecord [ last ] = bal; 

} 

} 


Listing A. 16: Concrete specification, Empty Log 


A.3.3 Replace 


public class Log { 

/*@ accessible \inv:this.*; @i=/ 

//@ public invariant logRecord. length > 0; 
protected /*@ spec public @*/ int [] logRecord; 

//@ public invariant last >=— 1 last < logRecord. length; 

protected /*@ spec public @*/ int last; 

public Log(int size) { 

this. logRecord = new int [ size ]; 
last = —1; 

} 

/*@ public normaLbehavior 
@ requires true; 

@ ensures (\result = ((logRecord. length — 1 = \old(last)) ? 0 : \old(last) + 1)) 
@ ((logRecord. length — 1 = \old(last)) ==> 

@ ( \fresh(logRecord) && 

@ (\forall int i; i>=0 i<logRccord. length; logRecord[i] = 0) &fe 

@ logRecord.length = \old(logRecord.length))) &fe 

@ ((logRecord. length — 1 > \old(last)) ==> logRecord = \old (logRecord)); 

@ assignable logRecord; 

<©*/ 

public int rotateLogQ { 

if (last = logRecord.length — 1) { 

logRecord = new int [logRecord. length ]; 

return 0; 

} else { 

return last + 1; 

} 

} 

/*@ public normaLbehavior 
@ requires true; 

@ ensures last = (\old(last) 

@ logRecord [last] 


= \old(logRecord.length) — 1 ? 0 : \old(last) + 1) &fc 
— bal; 
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©assignable logRecord, last, logRecord[last + 1]; 

@1=/ 

public void add(int bal) { 

last = rotateLog(); 

logRecord [ last ] = bal; 

} 

} _ 

Listing A.17: Concrete specification, Replace Log 


71 



